In order for members to use Personal Community they first must enroll in the application. Personal Community supports two mechanisms for onboarding members:

• Enrollment using Personal Community Credentials  - Personal Community credentials consist of a username and password that Personal Community authenticates for account access. These credentials are created during member enrollment. Typical credential set workflows, such as changing a member’s password, take place within Personal Community. There are three options when using Personal Community credentials:
  • Point-of-Care Enrollment  - the prospective member works with a representative of the organization in person, usually at the location of a care provider, to initiate the enrollment process.
  • Self-Requested Enrollment  - the member initiates the process by submitting an enrollment request. If the member is registered in the MPI, a Personal Community account is created.
  • Automated Enrollment - an external system provides identifiers programmatically to initiate the enrollment process. After populating accounts for these patients, Personal Community automatically emails these prospective members with information to complete the enrollment process.
• Enrollment using External Credentials  - in this mechanism, Personal Community is integrated with an external identity provider (such as NHS login or UAE Pass). Prospective members enroll themselves by authenticating with the external identity provider, 

Personal Community also provides the ability to send digital invitations to prospective members to enroll in the application.

Once members are enrolled, system administrators can use the Workbench to handle system account tasks, such as:

• Minimum age requirements
• Authentication requirements, including required fields for enrollment
• Account security settings
• Proxy relationship management

You must make decisions regarding enrollment:

Digital Invitation to Enroll

• Whether or not to support digital enrollment invitations.  
• What workflows within your organization would trigger an automatic invitation to enroll.
• Whether or not each workflow requires a distinct message for the invitation.

Supported Enrollment Mechanisms

You must decide if you will allow patients to enroll using Personal Community credentials, external credentials, or both. Allowing use of external credentials requires implementation and configuration to establish a connection between your system and the external identity provider.

With point-of-care enrollment, a Workbench user or other representative of your organization initially enrolls the prospective member. Once the Workbench user completes this process, the prospective member is provided with an access code – either on paper or in an email from Personal Community. The prospective member then has a specified amount of time, say 72 hours (specified by the   Pending User Expiration Time   field), to complete the next step and activate their Personal Community account. (If this does not occur, a Workbench user may need to extend the lifetime of the account activation code.) The prospective member then completes the process of activating their   account   and receives mail containing a link to Personal Community.

2.1.2. Business Decisions

You must make decisions regarding the following issues:

Email policy options

During enrollment, Personal Community can handle email addresses in one of several ways:

• Accept user-supplied email  – Allows the prospective member to supply an email address during the in-person enrollment process. This option depends on the representative to authoritatively authenticate the member’s identity during the enrollment process.

• Use MPI if present but require printed activation if not  – Attempts to use the email address that is present for the prospective member in the  Master Patient Index  (MPI). If there is no email address available, Personal Community requires that the prospective member receive the access code in person or by postal mail (which is sent to the patient home address in the organization system). This option depends on the accuracy of the email or physical address in the MPI.

• Accept user-supplied email if no MPI email  – Attempts to use the patient email address present for the prospective member in the MPI. If there is no email address available, Personal Community allows the prospective member to supply an email address during the in-person enrollment process. This option depends on the representative to authoritatively authenticate the prospective member’s identity during the enrollment process.

Use of temporary passphrases

A temporary passphrase assists with prospective member authentication during enrollment. Decisions regarding them are:

• Whether temporary passphrases will be allowed

• Whether temporary passphrases will be required

• Minimum requirements for length, character mix, and so on

Required enrollment fields

You can require up to three pieces of information, including two demographic fields and a temporary passphrase, for enrollment to succeed. If you will be using both point-of-care and automated enrollment, InterSystems strongly recommends that temporary passphrase be one of the fields you choose.

With self-requested enrollment, the prospective member fills out the online form to establish an account. Even though the process begins with the prospective member, it requires that there is already an entry for the prospective member in the Master Patient Index. Once a prospective member has completed an enrollment request, a Workbench user looks them up, matches the request to a patient already registered in the MPI, and associates the registered patient with the Personal Community account being created. At this point, the prospective member has an account on the system; they receive an email with a link to activate the account, choose a username, and perform any other setup tasks.

2.1.4. Business Decisions

You must make decisions regarding the following issues:

Required Enrollment Fields

You can require up to two demographic fields for enrollment to succeed.

Email Policy Option

Once enrolled, the prospective member receives email from Personal Community at a specified email address. As a policy decision, you need to decide how the organization handles the situation if a prospective member attempts to enroll but has no email address in the MPI. Personal Community can handle email addresses in one of several ways:

• Accept user-supplied email – Whether or not Personal Community uses the email address that the prospective member supplies for all its communications. In a production environment, it is recommended that Personal Community externally verify the validity of the email address entered by the prospective member. For example, an organization might send a printed copy of the access code to the prospective member’s physical address that is on file; the prospective member then must enter that code in order to complete enrollment.
• Reject if no email in MPI – Only allows the prospective member to enroll if there already is an email address present for them in the MPI. If the system has an email address, this is in the MPI, and Personal Community uses it as the prospective member’s email. If there is no email for the prospective member in the MPI, the enrollment is rejected.

• Use MPI email if present but require printed activation if not – Allows the prospective member to enroll if there is already an email address present for them in the MPI; if there is no address on file, this requires that the prospective member has a printed access code to enter. If the system has an email address, this is in the MPI, and Personal Community uses it as the prospective member’s email. This option is recommended for use in a production environment. If no MPI email is found, it requires the representative to print and send the access code to the prospective member’s street address; this provides increased security. Note that this option depends on the accuracy of the address in the MPI.

• Accept user-supplied email if no MPI mail – Attempts to use the email address present in the MPI; if there is no email address available, uses the email address supplied by the prospective member in the self-enrollment form. In a production environment, it is recommended that Personal Community externally verify the validity of the email address entered by the prospective member. For example, an organization might send a printed copy of the access code to the prospective member’s physical address that is on file; the prospective member then must enter that code in order to complete enrollment.

This section describes the business decisions that are required in order to implement automated enrollment. With automated enrollment, you can connect your EMR as an external system to initiate the enrollment process programmatically. Automated enrollment supports custom code that populates member accounts as the initial part of the enrollment process. This process has several stages:

1. Your organization uses code that communicates with the Personal Community infrastructure. This code provides patient identifiers programmatically to initiate the enrollment process.

2. Once the accounts have been populated, Personal Community automatically emails prospective members to inform them that they can complete the enrollment process and set up their accounts.

3. Prospective members use the account activation information that they have received to enroll in Personal Community.

The principal advantage of automated enrollment is that it allows efficient processing of a large number of enrollments at once.

When using automated enrollment, you must:

• Ensure that the data for each prospective member is valid.

• Perform prospective member identity validation as part of the activation process (using mechanisms that Personal Community provides).

2.1.6. Business Decisions

You must make decisions regarding the following issues:

Required Enrollment Fields

You can require up to three pieces of information, including two demographic fields and a temporary passphrase, for enrollment to succeed. In the case of automated enrollment, InterSystems strongly recommends that temporary passphrase be one of the fields you choose.

Email Policy Options

Once enrolled, the prospective member receives email from Personal Community at a specified email address. Personal Community can handle email addresses in one of two ways:

• Use supplied email   — Uses the email address supplied by the external system.

• Use MPI email  — Uses the email address present in the MPI. If there is no such email address, the enrollment is rejected.

Identifier for Default Enrolling User

Before you begin enrolling prospective members, you must specify an identifier for the default “enrolling user” in the settings for  HSPortal_APIEnrollmentService . This identifier, which can be any combination of characters, will appear in your system log if an enrollment request does not specify an enrolling user.

When prospective members enroll in Personal Community, they are subject to a number of policies. This section describes those policies, about which you must make selections in accordance with your organization's larger policies.

2.2.1. Business Decisions

You must make decisions regarding the following policy decisions BEFORE you begin member enrollment:

Minimum permitted age for access to the Personal Community

The minimum age in years to be able to use Personal Community as a principal without a proxy. 

Whether or not to notify members if their password has been changed

Whether or not to send members an email that their password has been changed. If selected, then the address that receives the mail depends on the email configuration option chosen above. 

Whether or not to notify members when they have received a new message within Personal Community

Whether or not to send members an email when they have received a new message within Personal Community.

Whether or not point-of-care or automated enrollment requires a passphrase for authentication

Whether or not the point-of-care or automated enrollment process requires the use of passphrases for authentication to complete enrollment. 

Required fields for enrollment

Your organization can choose at least one and up to two member demographic fields that can be required for enrollment.

During implementation planning, you should identify the fields you want to require for enrollment. If you want to rely on the supplied defaults of social security number or mother’s maiden name as options, no further planning is required in this area. However, if those fields are not suitable choices, you must:

• Identify the fields that you want to use

• Ensure that those fields are available for use

• Decide whether to require a temporary passphrase for point-of-care enrollment in addition to any other fields you have chosen

• Determine the display values for those fields in the Workbench and Personal Community

• Determine any required formatting rules for those fields (for example, requiring that a certain number of digits be entered for a driver’s license number)

Password reset expiration time

The duration (in hours) that a password reset token is valid. After this amount of time, the token expires and the prospective member must request another.

Pending user expiration time

The duration (in hours) that the token required for setting up an account is valid. If the prospective member does not complete enrollment by the end of the expiration time, the token for completing enrollment expires. 

The number of old passwords stored and not available for reuse

The number of old passwords that the system stores for a member. The system prevents members from reusing any of these stored passwords. 

Source facilities for demographic information (automated enrollment)

When a member is enrolled with automated enrollment and the enrollment request uses an MRN from an EMR’s assigning authority, the demographic information that appears in Personal Community will be drawn from the healthcare facility that a) has that MRN on file and b) has the best (lowest) tier ranking and latest create or update time in the associated Unified Care Record. To ensure that healthcare facilities with trusted demographic information are among the best in terms of tier ranking, or to change demographic information in the Unified Care Record, the person who configures Unified Care Record will have to examine and, if necessary, adjust the configuration or demographic data.

Whether or not to automatically deactivate expired passwords

Member passwords have a maximum valid duration that is configurable. Your organization can choose to deactivate passwords whose duration has exceeded this limit. This requires members to change their password when they next sign in to Personal Community.

Whether or not to allow patients to review and update information during account activation

If using Personal Community credentials, at the end of account activation patients are presented with a page to review and update their preferences.  You must decide if you will let patients review and update their email address, mobile phone number, communication preference and preferred language.

When using point-of-care and/or automated enrollment, temporary passphrases may be used to authenticate members during enrollment. A   temporary passphrase   is a string of characters that is provided to or selected by a prospective member during the enrollment process. During account activation, the prospective member then enters this passphrase as a means of identity validation. The advantage of temporary passphrases is that they allow verification of prospective member identity without need for other identifying criteria; the disadvantage is that, in most cases, they require the patient or the patient’s proxy to be physically present.

You can specify that temporary passphrases will not be permitted, will be permitted, or will be required. If they are permitted or required, you can choose to have them emailed to prospective members during the enrollment process; further, if you choose to have them emailed to prospective members, you can also choose to have them generated automatically. All the fields that specify these selections are in the   Passphrase Configuration   section of the   Site Configuration   page in the Workbench   ( Setup  >  Site Configuration ) .

You must make decisions regarding the following issues:

Permitted or Required Passphrases

Whether temporary passphrases are required, permitted, or not in use.

Emailed Passphrases

Whether or not temporary passphrases will be emailed to prospective members who participate in point-of-care or automated enrollment.

Automatically Generated Passphrases

If you support emailing temporary passphrases, automatically generated passphrases are supported. If your implementation team chooses to generate passphrases automatically, then you can use the dictionary from which it generates passphrases in its default state or you can modify it.

Passphrase Characteristics

The minimum required attributes of prospective member passphrases in Personal Community:

• Minimum password length. 6 characters, by default.

• Minimum number of upper case characters. 0 characters, by default.

• Minimum number of lower case characters. 0 characters, by default.

• Minimum number of integer characters. 0 characters, by default.

• Minimum number of non-alphanumeric characters. 0 characters, by default.

Expanding the default dictionary

Whether or not to expand the default dictionary that checks for dictionary attacks. If you choose to do this, there are tasks for your development and administration teams; if not, there is nothing to do.

Different members complete the enrollment process at different speeds. Personal Community offers a mechanism to provide reminders to those who have begun but not completed the enrollment process ( pending accounts ). If a prospective member begins the process but does not complete it, after a certain amount of time, the prospective member’s activation code expires; in this case, the prospective member must request to renew their activation code.

Specifically, reminders are for members with a membership status of pending . If you use the service, each pending member receives an enrollment reminder on a regular basis until either completing enrollment or receiving the maximum number of reminders. When the service sends out the reminder, it also reactivates the pending member’s activation code for enrollment; the code is then valid for the duration that you specify when you configure the service.

If you choose, you can also configure the enrollment reminder service to delete pending accounts after the prospective member has received the maximum number of reminders and has not completed enrollment.

For example, if you wanted to give your members four weeks to complete enrollment, you could establish the following:

• Configure your activation code to last seven days.

• Establish reminders on a seven-day schedule, with a maximum of three reminders.

• Delete the pending member account if the member has not completed enrollment by week four.

You must make decisions regarding the following issues:

Frequency of Reminders

How frequently each pending member will receive reminders.

Reminder Email Content

The content of the reminder email.

Activation Code Duration

The duration for which the new activation code is valid.

Reminder Number Limit

The maximum number of reminders each pending member will receive

Incomplete Enrollment

Whether or not pending accounts are deleted if pending members do not complete enrollment

Deletion Email Content

If required, the content of the account deletion email

You must decide which external identity provider to support for member enrollment using external credentials. The options are:

• NHS login enrollment - The prospective member alone starts the process of enrolling in Personal Community, using their NHS login credentials. Representatives of your organization do not have to use the Workbench at any point of the enrollment process. This will require configuration to allow your system to communicate with NHS login.

  IMPORTANT

  Your organization must be granted permission by the NHS login team to use NHS login as an external identity provider.

• Enrollment with a different external identity provider - The prospective member alone starts the process of enrolling in Personal Community, using their credentials with an external identity provider. This will require implementation and configuration to allow your system to communicate with the external identity provider.

  IMPORTANT

  Your organization must have an established relationship with the external identity provider you choose in order to support use of their credentials for enrollment.

  Personal Community only supports connection to external identity providers using an OpenID Connect layer on top of OAuth 2.0.

When prospective members enroll in Personal Community, they are subject to a number of policies. This section describes those policies, about which you must make selections in accordance with your organization’s larger policies.

Business Decisions

You must make decisions regarding the following policy choices before you begin enrollment:

Minimum permitted age for access to Personal Community

The minimum age in years to be able to use Personal Community as a principal without a proxy. In the Workbench, this is the Minimum permitted age for access to the Personal Community field.

Whether or not to notify members when they have received a new message within Personal Community

Whether or not to send members an email when they have received a new message within Personal Community. In the Workbench, this is the Notify patients of new messages field.

Choice of unique identifier

You must determine which unique identifier, given by the external identity provider after authentication, to use for member validation. This identifier should match a value stored in the Unified Care Record Registry for the patient.

Filtering enrollment

Whether or not to only permit enrollment for members that meet certain conditions.

Whether or not to perform automated account management activities

Personal Community allows you to automate activities that may be legally required. You can automate:

• Disabling accounts for members below a certain age.

• Enabling accounts for members who reach a certain age.

• Ending proxy relationships for members who are principals and reach a specified age.

About Account Deactivation through the Workbench

If a member’s account must be deactivated for any reason (for example, the member has requested it or the member has died), a Workbench user with the appropriate permissions can deactivate the account.

If the member has a proxy, or is a proxy for someone else, that relationship is preserved. The member receives an email or a text message that their account has been deactivated and the deactivation is logged and visible within the Workbench. If the principal’s account is deactivated, the proxy can see the relationship in Personal Community, but cannot switch context into the member’s account.

Accounts may be reactivated later, in which case the member receives an email or text message notification and the event is logged to the Workbench. Should a principal’s account be reactivated, the proxy can once again switch context into the principal’s account in Personal Community.

About Account Reactivation through the Workbench

A Workbench user with the appropriate permissions can reactivate an account. When the reactivation is complete, the member receives email or text notification of the status change and the event is logged to the Workbench.

Personal Community allows you to automate various tasks related to enrollment and member accounts. This simplifies administration activities and ensures that accounts are managed in a manner that conforms to any legal requirements. The activities that you can automate are:

Whether or not to automatically disable accounts for members who are minors

Depending on the jurisdiction in which your organization is located, the law may require you to disable Personal Community accounts for minors when they reach a certain age, such as 10 or 13, until the minor provides explicit consent to use their account. Prior to that age, the minor would have an inactive/minor account, which a parent or guardian had established. If the jurisdiction requires for a child to consent personally to participate in services such as Personal Community once they've reached the relevant age, then Personal Community deactivates the account until the minor provides that consent.

Whether or not to automatically enable accounts for members reaching the age of majority

Depending on the jurisdiction in which your organization is located, the law may require you to automatically enable Personal Community accounts for minors who reach the age of majority. In following these legal requirements, you may have a range of choices available. You can implement an automated InterSystems IRIS for Health™ task to review all accounts regularly and enable accounts as required.

Whether or not to automatically terminate proxies for principals who are minors and reach a specified age

Depending on the jurisdiction in which your organization is located, the law may require you to disable Personal Community proxy accounts that represent minors, when those minors reach a certain age. In following these legal requirements, you may have a range of choices available. You can implement an automated InterSystems IRIS for Health task to review all accounts regularly and disable proxies as required. An account that has been disabled for this reason is referred to as an inactive/minor account.

You must make decisions regarding the following issues:

Determine Relevant Laws

If these activities are for legal compliance, which laws are relevant in your jurisdiction.

Compliance with Laws

How your organization will comply with these laws, through system tasks or otherwise.

Supported System Tasks

Which system tasks will be supported.

System Task Frequency

How often each supported system task will run.

An important part of a patients account management is properly capturing and updating their profile. In the Account Summary Section, patients can update their profile information including address, contact information and communication preferences. This section will allow patient's to change and update their:

• Address (for physical letters)
• Email
• Mobile Phone
• Preferred Language
• Communication Preferences

If you want to notify external systems of status changes to an account or MPI record, you can use the Status Change Service. With the Status Change Service, you can configure Personal Community to send notifications upon the following events:

• A new prospective member is enrolled in Personal Community.

• A prospective member’s account is activated and they become a member of Personal Community.

• A member’s account is deactivated.

• A member’s account is reactivated.

• A change is made to a member’s MPI record in the EMR associated with Personal Community.

In addition, for accounts with Personal Community credentials, you can configure Personal Community to send notifications upon the following events:

• An account for a pending member is deleted.

You must make decisions regarding the following issues:

Status Change Notifications

Whether you want to notify external systems of status changes to user accounts:

Selection of Notifications

If you notify external systems, which types of events you send notifications for.

You must make decisions regarding the following issues:

Password Characteristics

The minimum required attributes of member passwords:

• Minimum password length. 6 characters, by default.

• Minimum number of upper case characters. 1 character, by default.

• Minimum number of lower case characters. 1 character, by default.

• Minimum number of integer characters. 1 character, by default.

• Minimum number of non-alphanumeric characters. 0 characters, by default.

Password Expiration

How long a member’s password is valid. By default, passwords do not expire. Personal Community supports the ability to automatically disable password after a configurable period of time.

Checking for Basic Dictionary Attacks

Whether or not members will be prevented from using easily guessed passwords by comparing passwords to a list of strings that attackers frequently check. This feature is enabled by default.

Expanding the Default Dictionary

Whether or not to expand the default dictionary that checks for dictionary attacks. If you choose to do this, there are tasks for your implementation team; if not, there is nothing to do.

Number of Iterations for the Encryption Algorithm

The number of times that the encryption algorithm is run. This is set to 65536, by default.

Number of Bytes of Salt

The number of bytes of random data introduced into encryption process. This is set to 64, by default.

Personal Community tracks all failed login attempts for its members, which allows it to implement account lockout. Account lockout makes a member’s account unavailable after someone unsuccessfully attempts to log in to that account too frequently or too many times in a row. During account lockout, Personal Community prevents anyone from logging into the account, which can be either for a specified amount of time or indefinitely. For a temporary lockout, the member may request a password reset or can wait until the lockout ends. For an indefinite lockout, the member can unlock the account by resetting their password.

The rules for controlling account lockout are known as the account lockout policy . By default, Personal Community uses the following account lockout policy:

• If there are three failed login attempts within a five minute period, the account is locked for five minutes.

• If the member supplies a valid username and password while locked out, Personal Community displays a message indicating that the account is locked and how the member can correct the situation. This message is not displayed in response to invalid credentials.

The classes that implement the account lockout policy are known as lockout mechanisms . With the built-in lockout mechanisms, the following events can trigger account lockout:

1. A certain number of failed login attempts within a certain amount of time. This can result in a timed or indefinite lockout period. This is known as the time-based lockout mechanism .

2. A certain number of successive failed login attempts, without any limit on the duration of time during which they occur. This can result in a timed or indefinite lockout period. This is known as the successive failure lockout mechanism .

Personal Community also allows you to implement your own logic for a custom lockout mechanism.

You must make decisions regarding the following issues:

Using Built-in Mechanisms

Whether or not to use the built-in account lockout mechanism and, if so, whether to use one or both.

Lockout Triggers

If you are using either of the built-in mechanisms, what series of actions will trigger lockout and the lockout duration.

Customized Mechanism

If you are not using the built-in mechanisms:

• The logic to use.

• The series of actions that will trigger lockout.

• The lockout duration.

Built-in Lockout Messages

Whether or not to use the built-in lockout messages.

Customized Lockout Text

If you are not using the built-in messages, what text to use for these messages

Personal Community supports the use of two-factor authentication to add a second layer of security to patient accounts. Personal Community uses a time-based one-time password (OTP) mechanism; after entering their account password, the patient enters a verification code sent to their mobile phone or email. This verification code expires after 6 minutes and the member can only use it a single time.

Business Decisions

You must make decisions regarding the following issues:

Enabling Two-Factor Authentication

Whether or not to enable two-factor authentication for patient sign-in.

A  proxy user   (also known as a proxy ) is a patient’s legal representative for interactions with the organization’s version of the Personal Community. One member may serve as a proxy for another for a number of reasons, such as:

• A parent or guardian representing a child.

• A family member or guardian representing someone with a temporary or long-term incapacity, such a patient receiving anesthesia or suffering from dementia, respectively.

• A family member representing another family member for administrative or convenience reasons, such as one spouse representing another.

The patient being represented in the  proxy relationship  is known as the  principal .

A proxy user may also be a patient in their own right. Alternately, they may have a  proxy-only account  with Personal Community

When your implementation team is setting up policies and constraints for proxies, there are the following considerations:

• Legal requirements, if any, for who can serve as a proxy on behalf of a patient. This may include:

  • Required existing relationships, if any, such as parent-child, spouse-spouse, legal guardian-ward.

  • Required circumstances, if any, such as that only an incapacitated patient may have a proxy or that only the legally established guardian of a patient may serve as a proxy.

  • Any other requirements or prohibitions on who can serve as the proxy for a patient.

• Any policies or technical requirements for the process of establishing a proxy. This may include:

  • Requirements for validating the proxy’s identity.

  • Any required prerequisites, such as forms that have been filed.

  • Which members of the organization’s staff are allowed to make one member a proxy for another.

  • Any other aspects of the workflow, such as if the process must occur with the proxy and/or principal present in person for establishing the relationship.

  • Determining the means of securing the connection that the proxy API uses.

    Note

    You cannot establish a proxy for a member without an  account . The member must have a membership status of pending, active, or inactive/minor.

• Preparing for fact that Personal Community adds the proxy to the organization’s Master Patient Index when establishing the proxy relationship. The organization may need to plan for this, such as if the patient population is exclusively made up of minors and proxies are all adults.

You must make decisions regarding the following issues:

Proxy User Requirements

The requirements of who can serve as a proxy user. This includes items such as minimum age.

Process Requirements

The requirements for the process by which the proxy relationship is set up.

Validation Method

The method by which the proxy user's identity is validated.

Proxy Notifications

Whether or not to notify proxies of new messages in their principals' Personal Community inboxes.

Translations

Whether translations are needed for proxy relationship display values.

For greater ease of use, Personal Community is installed with a set of personal relationship descriptions, known as proxy relationship types , that display the personal relationship between proxy and principal in the public application and the Workbench. Each proxy relationship type has appropriate display values for the two people in the relationship.

• For example, if the proxy member is the principal’s son, the Workbench administrator might choose the “son” proxy relationship type while they are creating the proxy relationship.

• After the proxy relationship is created:

  • The principal can see their proxy when they view their account information.

  • The proxy can see their principal when they select their avatar on the top-right portion of the public application. From here, the proxy can select their principal's avatar to view their principal's account.

  • The Workbench administrator sees the relevant display value when viewing the member account for either principal or proxy.

• You can customize the default set of proxy relationship types by adding to, modifying, or disabling them. For example, you could disable the gendered proxy relationships and replace them with “parent-child” and “child-parent” relationships. You can also change the display text for any proxy relationship type.

• If your instance of Personal Community is localized for languages other than US English, you can provide translations for the display values associated with each proxy relationship type.

The default proxy relationship types available upon installation of Personal Community include:

You must make decisions regarding the following issues:

Set of Proxy Relationships

Whether the default installed set of proxy relationships, and their display values in US English, will be adequate as is, or whether the set of proxy relationships and their display values should be customized.

Display Value Translations

Whether translations in addition to US English are needed for proxy relationship display values.

Depending on your organization's (or region's) policies, you may need to allow a patient view and/or manage their consent preferences. This includes services that patients can opt-in (or out) of. Examples of consent policies include:

• opting to receive marketing content
• sharing demographic information

 With Personal Community, you can import consent documents from an external system for the patient to submit their preferences for. To implement this feature, you must perform configuration on both Personal Community and your external system.

Business Decisions

You must make decisions regarding the following issues:

Viewing Consent Preferences

Whether or not to allow patients to view their consent preferences.

Consent Policies

Which consent policies to import from your external system to Personal Community for patient management.

Updating Consent Preferences

Whether or not to allow patients to manage their consent preferences.

Proxy Consent Management

Whether or not to allow proxies to manage their principals' consent preferences.