hl7.org website strategy health level seven ams functional ... requirements.pdfmaintain the...

Health Level Seven Last Updated May 27, 2008

HL7.org Website Strategy AMS Functional Requirements Version 3.0

Health Level Seven Strategy

Functional Requirements v. 3.0

© Copyright Health Level Seven, Inc. – 2008 All Rights Reserved. Information in this document is confidential and proprietary to Health Level Seven, Inc.

Table of Contents

Challenges.................................................................................................................. 2 Goals and Objectives.................................................................................................. 3 Strategic Areas of Focus............................................................................................. 3 Application Integration Points ................................................................................... 4

Membership Signup and Renewal ................................................................................ 4 Accounting - PeachTree.............................................................................................. 4 Credit Card Processing - SkipJack ................................................................................ 5 Permissions – SQL Roles / SharePoint .......................................................................... 5 Login....................................................................................................................... 5 Profile...................................................................................................................... 6 History .................................................................................................................... 6 Reporting................................................................................................................. 6 Co-Chair and Facilitator Status.................................................................................... 7 Work Group Association ............................................................................................. 7 Old Website.............................................................................................................. 7

User Roles & Entitlement ........................................................................................... 8 Business Rules.......................................................................................................... 8 User Archetypes........................................................................................................ 8

Permissions................................................................................................................ 9 Membership ............................................................................................................... 9

Membership Administrative Interface ........................................................................... 9 Reporting............................................................................................................... 11 History .................................................................................................................. 13 Membership Application ........................................................................................... 16 Membership Renewal ............................................................................................... 18 Member Profile ....................................................................................................... 20 Organizational Members........................................................................................... 22

Events ...................................................................................................................... 24 Event Types ........................................................................................................... 24 Event Administration ............................................................................................... 25 Event Setup ........................................................................................................... 25 Registration............................................................................................................ 28 Confirmation .......................................................................................................... 29 Post Registration..................................................................................................... 29 Reporting............................................................................................................... 30 Meeting Room Request Form .................................................................................... 30

Error Handling.......................................................................................................... 31




2

Overview

This document outlines the functional recommendations for an AMS to support the Membership and potentially Event areas of the HL7 website. Our goal is to simplify the administration process of the Membership while maintaining a seamless integration with our SharePoint portal and collaboration site. By providing a consistent, positive user experience for members and non-members alike – we hope to build a web presence that is better representative of the organization and its members, as well as a site that reflects the credibility of the organization.

Users should be able to transition seamlessly between the SharePoint site and AMS application. At the same time, the site will need to balance an intuitive user experience with the need to support and automate complex businesses processes. The AMS will need to be the central management point of users’ data and permissions.

Additionally, the new site information architecture will aim to support organic growth of the organization to accommodate the strategic changes that are being planned for the near future.

Challenges HL7 has evaluated their current Customer Relationship Management (CRM) system (Commence) and determined that it is not sufficiently capable of integrating with our SharePoint website. While we are very happy with the collaboration tools provided in our SharePoint website, it was determined that SharePoint 2007 out of the box does not provide an adequate interface for maintaining and administering a member-based organization. The resulting interfaces have created a very manual process that does not meet the overall project goals of reducing staff overhead. These findings set the foundation for the functional requirements that are outlined later in this document. Improving this experience is a foundational element in the new site strategy.

Additionally, several other key issues have been identified as important challenges that need to be addressed in the creation of a successful site:

• Complex transitions between interfaces

• Inadequate user and administrative validation

• Inflexible interfaces for producing useable systems

• Difficult/manual user and event administration

• Lack of reporting

Current Web Properties • http://www.hl7.org (Our old classic ASP and ColdFusion web presence) • http://demo.hl7.org (Our in process SharePoint 2007 collaboration portal)




3

Goals and Objectives • Integrate a robust membership application with the SharePoint collaboration portal • Support multiple user roles, and different views/capabilities assigned to each role • Upgrade membership systems to automate current manual tasks • Manage member’s information and access roles through a centralized and seamless

interface • Replace the event management system with a system that can be administered by

event management personnel • Integrate of third party off the shelf tools whenever possible over custom developed

solutions • Create seamless transitions between multiple systems for both member and

administrator roles

Strategic Areas of Focus Membership Membership and collaboration are the cores of HL7’s website. The SharePoint collaboration portal that was developed builds a fully featured and expandable platform for the collaboration of our member. We seek to match that with an equally featured and expandable platform for managing our membership.

Event Management and Registration Events are the bread and butter of the organization, and thus it is important that our event system produces a highly useable and self-service registration while still allowing HL7 event management personnel to manage and update events without having to learn complex systems.

Automation This strategy will reduce the amount of manual effort expended on maintaining the entire HL7 site, allowing HL7 staff to focus on more strategic areas. In providing an integrated and centrally administered system, HL7.org will support more efficient processes, leading to enhanced productivity.




4

Application Integration Points

Membership Signup and Renewal Overview When a new member signs up or renews, their information should be stored in the AMS. The member will need to able to pay with a credit card (and thereby giving them instant access to the web site) or with a post submission payment process such as a check or wire transfer which should leave their account in a pending state. See the “Membership Application” requirements and “Membership Renewal” requirements for additional details about the process.

Current Setup A custom developed .NET web interface allows users to sign up and renew their membership. The membership information is stored in the SharePoint profile, with their access managed through SQL roles. Credit card orders are processed instantly through SkipJack, and the members’ status is updated. Post submission signups are processed, but are placed into a pending status via the SQL roles.

Integration The membership data should be stored in a centralized location, with the signup and renewal web interfaces directly updating the members’ status and access. New member accounts will need to create website profile accounts for the SharePoint website with appropriate access. We are open to updating and re-using the current .NET web interfaces or replacing them with web interfaces from the AMS.

Accounting - PeachTree Overview All payments (credit card, check, and Wire Transfer) need to be logged and exported in daily batches for PeachTree for accounting. Please see the “Membership History” and “Events” requirements for additional details.

Current Setup Credit card payments are automatically logged to a SQL database where they are exported daily via DTS to a DBF file for manual import into PeachTree. Checks and wire transfers are not currently included.

Integration We would prefer that all transactions are logged through the AMS to the current SQL database system so that no modifications will need to be done to export the transactions to PeachTree.




5

Credit Card Processing - SkipJack Overview Membership dues and bookstore transactions must be able to accept real time credit card payments. Please see the “Membership History” and “Events” requirements for additional details.

Current Setup Users paying with credit cards are processed through custom .NET interfaces, with the transactions processed via SkipJack. Credit Card transactions are logged to a SQL database which is later exported via DTS to a DBF file for import into PeachTree.

Integration Credit cards should be processed through SkipJack.

Permissions – SQL Roles / SharePoint Overview Changes to the members’ status within the AMS should update the members’ roles and permissions on the website. Updates should be managed through the users’ profile within the AMS admin interface. See the “User Roles Matrix” documentation and the “User Roles & Entitlement” Requirements for additional details regarding the permissions setup and the “Membership Administrative Interface” requirements for additional details regarding the membership admin area.

Current Setup From the member side, there are custom .NET interfaces that update and maintain the users’ associations to various roles as they change their status. SharePoint uses these roles to determine what access the user has on the website. On the admin side, the administrator logs into the SQL roles interface with the GUI tool provided by Microsoft to add and remove members from various roles to place them into the desired status.

Integration Because the SharePoint website permissions are set up to determine permissions based on the SQL roles, we would prefer to maintain the users’ permissions through the SQL roles. We are, however, open to alternative solutions that will allow website permissions to be managed through the AMS admin interfaces; note that this may require additional integration into the SharePoint website.

Login Overview The members must log in once and be able to access both the SharePoint collaboration website, and their profile information in the AMS.

Current Setup With the user’s profile stored within SharePoint, the user logs into the website through forms based authentication, and is allowed access to the website and their profile through the SharePoint profile management.

Integration A single sign-on will need to be implemented so that the user can seamlessly move between the SharePoint collaboration website and the AMS. Password changes should be seamless.




6

Profile Overview The user should be able to update the available fields in their profile through the website, with their changes recorded automatically in the AMS. Administrators must also be able to manage all of the users’ information and perform status changes and updates. Please see the “Member Profile” requirements and “Profile Fields Map” documentation for additional details regarding the information that is stored in the users’ profile and the “Membership Administrative Interface” requirements for additional details regarding the membership admin area.

Current Setup From both the member and admin side, members profile information is managed through the SharePoint profiles.

Integration The SharePoint website uses information found in the users’ profile to populate various areas of the website (co-chair information in the work groups, public profile pages linked throughout the system, etc…). The solution will require that either the AMS maintain the SharePoint profiles seamlessly, or that the SharePoint site be modified to pull profile information from the AMS. Reports within the AMS will need to access this information.

History Overview Historical events need to be recorded and reported within the users’ profile in the admin interface. Please see the “Membership History” requirements for additional details, and the “Membership Administrative Interface” requirements for additional details regarding the membership admin area.

Current Setup Credit card accounting information and event signup history are stored in a SQL table. The remaining history items are not currently being stored. There is no interface for viewing the history of a member.

Integration The user will need to be able to view the history of the user within the user profile interface of the member profile. The existing history items may be moved to the AMS history, or the AMS may store its history in the existing history table. Reports within the AMS will need to access this information.

Reporting Overview The administrator needs to be able to run a number of canned and ad-hoc reports. Please see the “Reporting” requirements for additional details.

Current Setup There is currently no reporting capabilities setup.

Integration Data must be pulled from the member’s profile, group associations (work groups, administrative groups, co-chairs, facilitators), events, history, and accounting.




7

Co-Chair and Facilitator Status Overview The administrator will need to be able to assign a user the co-chair or facilitator role for a specific Work Group. Note that there are multiple types of facilitators. This association will need to be shown on the users’ profile, as well as on the co-chair / facilitator page within the Work Groups.

Current Setup Members are associated with a Work Group manually through a SharePoint list. The Work Group page has a custom web part that uses this list to determine who to display and then pulls the profile information from the users SharePoint profile.

Integration Co-Chair and facilitator status will need to be managed within the AMS. The AMS will need to either maintain the existing co-chair facilitator list within SharePoint or the Work Group co-chair / facilitator page will need to be modified to grab the information from the AMS. Reports within the AMS will need to access this information.

Work Group Association Overview A member has the option of associating his or herself with a work group. Doing so will make the calls, news, and events for that Work Group to appear on that user's MyHL7 page.

Current Setup Within the MyHL7 area there is a process for members to associate themselves to a Work Group. We believe that this is maintained through a SharePoint list. There is no method of viewing or editing this relationship in the admin membership interface.

Integration Work Group association will need to be managed through the AMS. The user will need to be able to view a list of Work Groups and select which they would like to be associated with. They should be able to select multiple work groups. The AMS will need to either maintain the existing work group association list within SharePoint or the MyHL7 page will need to be modified to grab the information from the AMS. Reports within the AMS will need to access this information.

Old Website Overview Portions of the old website will remain in service until the next phase of development. The user will need to be able to seamlessly move between the different sites.

Current Setup A .NET page is set up on the SharePoint site that transfers the login information to a form on the old website which authenticates the user. The old website uses web services to gather information from the profile.

Integration A single sign-on solution will need to be setup/maintained between the different systems. Profile information will need to be accessible through web services, API, or database calls.




8

User Roles & Entitlement The HL7.org SharePoint collaboration portal has been designed to manage entitlement through user roles and archetypes. The AMS should integrate with these roles and archetypes allowing the administrator to move the user between the roles as well as specify access and responsibilities within the user’s profile.

See the User Roles Matrix for additional requirements and information.

Business Rules • Roles will be based on a user archetype model

• Roles and responsibilities can be controlled at the archetype level by the HL7 Administrator

• Assigning an archetype to a user is done by default at registration, but can be refined by the HL7 staff or HL7 Administrator

• Archetypes are not mutually exclusive; one user can be assigned to multiple archetypes

User Archetypes This list is a broad overview of some archetypes that have been identified in the discovery process. This list is not comprehensive, as the system will accommodate flexibility to grow and change as needed. Further roles are detailed in the User Roles Matrix.

• Visitors – Browsers looking to find out more about the HL7 organization, initiatives and the standards themselves. General users are potential volunteers or members.

• Participant - Users who are not members, but who maintain a profile within the site so that they can be listed as certified, make purchases, participate in a listserv or discussion forums, or flag bookmarked content. These users can also be granted additional rights by administrative staff.

• Students – Discounted members, who are actively contributing to the HL7 organization at the working group level, but do not retain voting rights.

• Benefactors - corporate, non-voting members, with download privileges.

• Member – A paid or compensated member of HL7 (includes Individual and Organizational members), with download privileges, balloting rights and discounts.

• Working Group Facilitator: Can be assigned by staff or the co-chair to administrate members and content at the working group level.

• Empowered Participant – Participant who is assigned special rights in order to accomplish a specific goal.

• Co-Chair: Maintains members and content at the working group level. This user has unique balloting rights.

• Board Member – Can participate at the working group level, but also can participate in board e-ballot process, and see/manage private/board-related content.

• HL7 Staff: This user will be able to manipulate most content, administer other users, determine featured pieces of content and messages, and access reporting tools.

• HL7 Administrator: This user will have full access rights to the system.




9

Permissions

See the User Roles Matrix document for additional information.

Membership

Membership Administrative Interface The system is currently designed with some information stored in various systems (SharePoint Profiles, SharePoint lists, SQL Roles and SQL tables). With each of these systems, there is a different interface and a different method of searching the data. The current admin process requires accessing all 3 systems (finding the member manually each time) and 40+ clicks to move from pending to approved, yet the member can renew their membership with just a few logical clicks. We would like to leverage existing code in the member area to allow the admin to renew as easily as the member can renew.

We are looking to have a user friendly interface created to allow the management of users. The system must be simple and logical to operate with as little manual effort to transition users from one status to another. The system must validate the users’ entries to prevent the user from entering bad data. The user should be assumed to be familiar with computers, but not with SharePoint or SQL.

1. Current data setup

1.1. Profile information

1.1.1. Base information for profiles is stored in SharePoint profile – Managed through “out of the box” (OOB) SharePoint interface

1.1.2. Extended profile information is stored in lists (One to Many relationships such as Co-chairs, Facilitators, Working Group Associations, etc…) – Managed independently by accessing each list

1.2. Permissions

1.2.1. The users roles are stored in SQL Roles – Managed through Microsoft provided SQL Roles HTML interface

1.3. History (Membership and Accounting)

1.3.1. Neither is being tracked at the moment through SharePoint

2. The administrator should be able to transition from one area of the profile (profile, history, associated work groups, etc…) to the next without losing the current user.

3. Members will need to be able to be filtered and sorted based on all fields within their profile (name, email, organization, status, etc…).




10

4. Profile

4.1. When a user edits their profile, the look and feel of the profile should match the look and feel of the membership signup (it currently reflects the OOB SharePoint interface).

4.2. Options should be simple and self documenting

4.2.1. Use Cases

4.2.1.1. Organization levels should be a drop down instead of a numeric input requiring a separate document to decipher the values

4.3. Options should be available as checkboxes, radio options, or dropdowns to make selection user friendly and web standard.

4.4. The system should validate the users/admin entries and prevent them from checking options that would render the user in an invalid state. Many of these should be removed with automation.

4.4.1. Use Cases

4.4.1.1. Do not allow the administrator to process the renewal without specifying the users’ role

4.4.1.2. Do not allow the administrator to remove the user from the pending status without adding them to the active status and vice-versa

4.4.1.3. When moving the user from pending to active, systematically activate their ability to post jobs, update their status, etc…

5. Renewals

5.1. Renewing a member from the administrative end should be as easy as renewing ones membership from the member perspective.

5.1.1. Re-use the code from the membership side to perform the administrative functions

5.2. Automatically update the member upon renewal.

5.2.1. Please see the membership renewal process for more information (Status, Renewal Date, History, Permissions, etc…)

5.3. Administrator needs to be able to view members that have expired or are about to expire.

6. Organizational Members

6.1. Need to be able to view and manage the voting members of an organization when looking at the key member.

6.1.1. This includes adding, removing, and changing voting members

6.1.2. Upon expiration, an organizational profile should not appear on the website (Benefactor and supporter pages and organizational member search)

6.2. Need to be able to search by organization.




11

7. Check and Wire Transfers

7.1. When processing Check and Wire transfers, the system should provide a simple automated user interface for moving users from “on hold” to “approved”.

7.1.1. Status

7.1.2. History

7.1.3. Permissions

7.1.4. Voting Members

8. Create groups and associate users

8.1. Groups must be created on the fly, and users associated with the groups

8.2. Administrator needs to be able to view all members associated with a group

8.3. Add / remove members from a group

8.4. Remove a group (does not delete the members, just removes the group itself)

9. Ability to create and apply membership discounts to members

9.1. Discounts should have a name and either a percentage off or an amount off

9.2. Member should be able to see the discount name and amount along with their renewal rates

Reporting

The current system does not contain any reporting functionality. The system will need to be set up to allow for running existing reports and generating new reports (both on an ad-hoc and saved report basis). See the “Report Samples” for additional information.

1. Reports need to be ‘As Needed’ or Weekly

1.1. Unknown at this time exactly what reports will be needed based upon how the system will work. We will need to have the ability to set up specific on-going reports that can be automatically generated.

2. Existing reports that need to be duplicated

2.1. New joined members within a date range to generate confirmation letter, shipping report and mailing labels to send new member kits

2.1.1. Search Criteria: renewed date, new join date to indicate they’re new

2.1.2. Fields: Name, address, firm/org, member type, salutation

2.1.3. This should include all members associated with an organization as well as the key member

2.2. Renewed members within a date range to generate confirmation letter, shipping report and mailing labels

2.2.1. Search Criteria: renewed date

2.2.2. Fields: Name, address, firm/org, member type, salutation

2.2.3. This should include all members associated with an organization as well as the key member




12

2.3. Members not renewed within a date range

2.3.1. Search Criteria: expiration date

2.3.2. Fields: Name, address, firm/org, member type, other fields for letter verbiage?

2.4. Ability to send emails to a select group of members

2.4.1. Search Criteria: Examples: Special emails to people whose memberships are about to expire or whose membership has expired within a certain time frame

2.4.2. Fields: Name, address, other fields for the email verbiage

2.5. Mailing labels and shipping report for opt-in mailings

2.5.1. Search Criteria: When “Would you like to receive hard copies of newsletters and event brochures” on profile is checked

2.5.2. Fields: Name, address

2.6. Mailing labels and shipping report for sending new standards to members

2.6.1. Search criteria: All active members.

2.6.2. Fields: Name, address

3. Monthly:

3.1. New Voting Members by Type by date range

3.1.1. Search criteria: New Joined Date FROM … TO. This could be an automated monthly report. We should also have the ability to select any From and To date for special reports.

3.1.2. Fields: New Joined Date, Name, Firm, Membership Type, Membership Category

3.2. Renewed Voting Members by Type by date range

3.2.1. Search criteria: Renew Date FROM … TO. This could be an automated monthly report. We should also have the ability to select any From and To date for special reports.

3.2.2. Fields: Renew Date, Name, Firm, Membership Type, Membership Category

3.3. Expired Voting Members by Type by date range

3.3.1. Search criteria: Due Date FROM … TO. This could be an automated monthly report for the previous month. We should also have the ability to select any FROM and TO date for special reports.

3.3.2. Fields: Due Date, Name, Firm, Membership Type, and Membership Category

3.4. Full membership report alphabetically and by type




13

4. The user needs to be able to filter specify information to be included in ad-hoc reports from the following areas of information:

4.1. Membership Profile

4.2. Co-chair / Facilitator association

4.3. Work Group Association

4.4. History (As detailed in the History section)

4.5. Events

4.6. E-Commerce and accounting

5. Reports need to be able to be exported to Excel

5.1. Use Cases

5.1.1. Membership process involves sending out Mail Merge templates and it needs a source

History

The current SharePoint system has limited storage of history • E-Commerce transactions are stored in SQL

o These are exported daily into a DBF file using DTS for use in Peachtree accounting

• Event registrations are stored in a SQL database

1. Membership

1.1. When a user creates a profile

1.1.1. This is a one time event

1.1.2. Use Cases

1.1.2.1. Tells HL7 when they first got involved/interested in the org

1.1.2.2. When profiles were created so they can market to the groups to solicit membership

1.1.2.3. For every X participants, Y become members

1.1.2.4. Search on profile join dates - participant

1.2. When a user becomes a member

1.2.1. This is a not one time event, membership may lapse and be re-activated multiple times during the life of the member

1.2.2. If membership is renewed but does not lapse a record will not be created

1.2.3. Reactivation of an expired membership will trigger a record to be added to this history item

1.2.4. Use Cases

1.2.4.1. To generate batch of letters that is used in the manual "snail" mail process

1.2.4.2. Becoming a NEW member for the first time

1.2.4.3. Reactivating a membership




14

1.3. When membership status changes (expires, renews, reactivates, changes membership type)

1.3.1. Not a one time event

1.3.2. Need to store what status they were before the change (Changed from pending to active)

1.3.3. Use Cases

1.3.3.1. Report on how many memberships expired each month

1.3.3.2. Report on how many members renewed their membership in a given month

1.4. When they change employers

1.4.1. Not a one time event

1.4.2. Date employer was updated in the profile (current date)

1.4.3. What is the old employer name

1.4.4. Use Case

1.4.4.1. User left one company and joined another - for org history

1.5. When a Key Member Added or Removed a voting member

1.5.1. Put a history record in the Voting Member showing the change

1.5.2. Put a history record in the Key Member showing that they changed voting members

1.5.3. Date of addition or removal

2. Working Groups

2.1. Co-Chairs

2.1.1. Co-chair election date (assigned)

2.1.2. Co-chair expiration date

2.1.3. What committee they were co-chairing

2.1.4. Committees would include the TSC & Steering Divisions (4 of them)

2.1.5. Use Case

2.1.5.1. Want to know that a member served as a co-chair and when their term(s) were held

2.1.5.2. Searching by Committee

2.2. Facilitator

2.2.1. Type of Facilitator

2.2.2. Which committee

2.2.3. Assigned date

2.2.4. Expired date




15

2.3. Member

2.3.1. When a member joins a working group

2.3.2. When a member leaves a working group

2.3.3. Which working group

3. Events

3.1. Registration

3.1.1. Event Registration Date

3.1.2. Which event for which the user has registered

3.1.3. Use Cases

3.1.3.1. Can not be a board member unless you attend two events a year

3.1.3.2. Can not be a co-chair unless you attend X meetings per year

3.2. Edits and Cancellations

3.2.1. If the user cancels their event Registration, cancellation date

3.2.2. Date a user edits their registration (date only, no detail of the edit)

4. Advisory Committee

4.1. Appointed Date

4.2. Expired Date

4.3. When someone is appointed to Advisory Committee (as we track that as well); include expiration date.

4.4. It is not required to be a voting member. This person could be an empowered participant.

5. Board Members/International affiliate chairs (IAC)

5.1. Title

5.2. Elected date

5.3. Expired Date

5.4. Board or IA Country

6. eCommerce

6.1. Date of payment

6.2. Payment type (CC, Check, Wire)

6.3. Amount of payment

6.4. Payment was for?

6.4.1. Event Registration

6.4.2. Bookstore

6.4.2.1. Include Individual Items Purchased

6.4.3. Memberships




16

7. Manual Edits and Updates

7.1. Need an interface to manually enter historical information

7.2. Use Cases

7.2.1. We receive a wire transfer and need to manually enter historical information for the transaction so that it appears in the Peachtree export

7.3. User documentation for editing items in history

8. Existing historical information and accounting will need to be imported into the system from our Access / SQL data.

8.1. See the “Profile Fields Map” for additional information

Membership Application

See the “Membership One Page” for additional information. Please see the “Screen Shots” for a visual representation of how this works in the current system.

1. Administrator needs to be able to perform all member-enabled functions from the Administrative area

2. Enter Membership Profile information

2.1. Enter information as defined in the Profile Fields Map

2.2. Have the system prevent duplicate memberships by validating applications against existing memberships

2.3. Users must select a Membership Type and Membership Category

2.3.1. See the Membership Type / Membership Category Matrix for additional information

2.3.2. Do not allow the user to select membership types and categories that are not valid

2.4. Student Members

2.4.1. Must enter their school and student ID (not validated for correctness)

3. Students and Individual members must fill out an HL7 Intellectual Property Compliance Form (IP Compliance form)

3.1. If the user checks that they are not in compliance, they should be redirected to the Organizational Membership application form

3.2. IP Compliance signature should be stored in the database




17


4.1. Must select an organizational level

4.1.1. See the Organizational Membership Level Dues Matrix for additional information

4.2. User signing up becomes the Key Member

4.3. Key Member can add up to the number of allotted Voting Members

4.4. Allow key member to optionally create an org profile at that time

4.4.1. Give member instructions on how to create this later if desired

4.5. See Organizational Members for additional information

5. Process payment type for membership applications by credit card, check, wire transfer

5.1. If selecting check or wire payment, provide mailing instructions, and allow user to easily print those instructions

6. Approval

6.1. Notify Director of Membership of new member record

6.2. Credit card transactions should be processed instantly, providing members instant access

6.3. Check or wire transfer payments should be placed into a pending status

6.3.1. Provide the ability for Director of Membership to approve pending memberships

6.3.1.1. Upon approval, update organization, key member and voting members; generate email notifications indicating approval

6.3.2. Organizational profiles should not appear on the site until the check/wire transfer clears

7. Post Application Process

7.1. User names and passwords are automatically generated and provided to the user

7.1.1. User names should be generated consistently (<firstname>_<lastname>)

7.1.1.1. Append a number to the end if the user name is already taken

7.1.2. Have the system independently provide the ability for users to request forgotten login IDs and passwords

7.1.3. Benefactor Key members should receive a generic User ID for their organization to use

7.2. Provide all members the ability to maintain their personal profile and Key member the ability to update the organizational profiles (See Member Profile section for further details regarding member profile fields)

7.3. Upon expiration, the members and organizational profile should not appear on the site, including member search, benefactors, supporters, co-chair, board page




18

Membership Renewal

Note that our current web system does not allow for members to change their type, category or level of membership when renewing online and thus the process is manual for the director of membership. We have outlined how we feel renewals and reactivations should be processed, but are open to ideas that will allow for an automated self-service process.

1. Administrator needs to be able to perform all member enabled functions from the Administrative area

2. Allow members to renew their own membership through the website

2.1. Compensated members should not be able to renew their membership, nor should they receive renewal notifications

3. System should allow renewals to occur no earlier than 90 days prior to expiration (i.e. “early renewal”)

3.1. Early renews should update the new renewal dates one year from the current renewal date regardless of how early they renewed

3.2. Early renewal should only be reflected in the next renewal date, all other changes should not appear until expiration

3.2.1. Use Cases

3.2.1.1. An organization renews 90 days prior to their expiration and adds or removes the number of voting members. The number of voting members should not be applied until the expiration date

3.2.1.2. An individual opts to renew their membership as an organizational benefactor member, their organizational profile should not appear on the benefactor page until their expiration date

4. Enter Membership Profile information

4.1. The same information available to change in their profile when editing their profile should be available to change when renewing

5. Membership Type, Category and Level

5.1. Participants and Members can upgrade their membership type upon renewal, but downgrading must be done by the membership administrator

5.1.1. Use Cases

5.1.1.1. Participants can become Students, Individual, or Organizational members

5.1.1.2. Students may become Individual or Organizational members

5.1.1.3. Individuals may become Organizational members

5.1.2. Notify the membership administrator upon any change in type

5.1.3. Place a note to indicate to the user that they must contact the membership administrator to change to a membership type that is not available to them upon renewal

5.1.3.1. The membership administrator should have the ability to downgrade a membership from Organizational to Individual, Student or Participant upon expiration




19

5.1.3.1.1. Keep the existing records for the Key and Voting members, change the voting member to the new status they wish to renew at (Individual, Student or Participant), and set the voting members to participants. Now the resulting profiles should be able to renew on their own with their credit card

5.2. Organizational members cannot change their Membership Category nor Organizational Level, these must be done by the membership administrator

5.2.1. Place a note to indicate to the user that they must contact the membership administrator to change to a membership level that is not available to them upon renewal


6.1. Only the key member can renew. Voting members status and permissions are tied to the key member

6.2. The key member has the ability to add or remove additionally purchased voting members or change existing members

6.3. See Organizational Members for additional information

7. Students and Individual members must fill out an HL7 Intellectual Property Compliance Form (IP Compliance form)

7.1. If the user checks that they are not in compliance, they should receive a message that they need to contact HQ to upgrade their membership. They should not be able to renew at that level.

7.2. IP Compliance signature should be stored in the database

8. Process renewals by credit card, check, wire transfer

8.1. Renewals should be processed upon expiration date or payment received date (whichever is later)

8.2. Credit card transactions should be processed instantly, updating expiration date

8.3. If selecting check or wire payment, provide mailing instructions, and allow user to easily print those instructions

8.4. Check or wire transfer payments should be placed into a pending status



9. Approval

9.1. Notify Director of Membership of new member record

9.2. Upon receipt of check or wire transfer:



9.2.2. Organizational profiles should not appear on the site until the check/wire transfer clears if the membership has already expired




20

10. Expiration

10.1. System should generate automatic expiration membership reminders and invoices, at specified intervals (for example 90-, 60-, 30-days)

10.2. System should expire a member (demote to a ‘participant’ role, leave their member type) upon reaching their end date

10.3. Once a member has expired, provide the ability for them to ‘reactivate’ their account within 1 year of expiration

10.3.1. Re-activation follows the same rules as renewals

10.3.2. Accounts renewed after 1 year will need to be done manually by the director of membership

10.3.2.1. History should reflect this lapse in membership

10.3.2.2. Member should be considered a new member as of the new renewal date, but not lose their history

10.3.2.3. Use case

10.3.2.3.1. If an organization renews their membership 2 years after expiring, they should show up on reports as a new member, but in looking at the history, you should be able to see the past status of the organization at various points in time

10.4. Upon expiration, the members and organizational profile should not appear on the site, including member search, benefactors, supporters, co-chairs, board page

Member Profile

See the “Profile Fields Map” for additional information and requirements.

1. As defined in the Profile Fields Map

1.1. Some fields will only be viewable by the Director of Membership or Administrators

1.2. Some fields, while viewable, won’t be editable by a member (example: First Name, Last Name)

1.3. Certain fields will be required based on membership type while not required for others (i.e. student membership requires student ID and school attending)

1.4. Certain fields will be available on the initial application, and others will be only available for the member to update after they have completed their application

2. Allow member to choose visibility for certain fields

2.1. Show only to me

2.2. Show to all members

2.2.1.1. Show to the public

3. All fields will be user ‘readable’ (i.e. the system may use a ‘0’ to process a ‘pending’ Status, but to users and administrators, the Status field will read ‘Pending’)




21

4. All profile data will need to be imported from our Commence database (exportable to Access or other format)

4.1. Profile

4.2. Accounting

4.3. History

4.4. Co-chair and Facilitator association

4.5. Board Association

4.6. Staff Association

5. Association to groups (workgroups, co-chairs, facilitators, boards, staff, etc.) should not be mutually exclusive

6. Member profile needs to be global, not US-centric

6.1. Phone Number Requirements

6.1.1. Each phone number (home, cell, fax, etc…) has a required country code field preceding it

6.1.2. The country code field will be a dropdown that contains the country and code

6.1.2.1. For example, it will show CAN +1 or GBR +44

6.1.2.2. Insure this is centralized and maintainable

6.1.3. When displaying phone numbers, display the 3-character country

6.1.3.1. Hence a UK/Great Britain phone number would be displayed as “GBR +44 1234-12313”

6.1.4. Validation

6.1.4.1. The phone number itself (area code, and local phone) will NOT be validated for length

6.1.4.2. The phone number must contain only numbers and dashes

6.1.4.3. There should be a message indicating this next to the entry and in any errors produced as a result of entering a bad number

6.2. International Country, State, Zip Requirements

6.2.1. Label state as State/Region

6.2.2. Default Country to “Select One”.

6.2.3. Country is a required field

6.2.3.1. If the United States is selected, fill the State/Region field with the states; otherwise leave as an entry field

7. Need to be able to add custom profile fields to the members profile through an interface

8. Need a field in each profile to indicate if that user has voting privileges (Could alternatively be done through a user role)

8.1. Should default to true for Individual, Organizational, and Compensated memberships, but should be able to be unchecked for any member on an individual basis.

9. All user profile information needs to be accessible through an API or database query so that legacy systems can access the information




22

Organizational Members 1. Key Member

1.1. Each organization has one key member

1.2. The voting members status are tied to the key member, so the key member must renew the organization membership

2. Voting Members

2.1. The key member may select up to the allotted number of voting members from available participants and members

2.1.1. Organizations won't have the authority to change a student to a voting member without requesting this through the Director of Membership

2.1.2. When a voting member is selected, their firm should reflect the same name as the key member. The voting member cannot change this firm value.

2.1.3. Organizations won’t have the authority to change an individual to an organizational voting member without requesting this through the Director of Membership.

2.1.3.1. Conversion of Individual Members to a voting member must be done manually as membership costs are not refundable

2.1.3.2. For an existing individual member, do not override their individual membership address with Org address info

2.1.4. Prorate a new member if added during the year

2.1.5. Use Case

2.1.5.1. A prorated amount is charged based upon the number of months left until the end of the membership year. For example, for an organizational membership which expires in 6 months, only half of the additional $600 fee ($300) would be charged. The membership dues amount, however, would increase by the full $600 for the renewal.

2.2. The key member may purchase additional voting members

2.2.1. When paying with a Wire / Transfer or check, these voting members will remain inactive

3. The key member may reduce the number of voting members upon renewal

3.1. Use Cases:

3.1.1. If their organizational level has changed; An organization with annual healthcare revenue of $5-10 Million with 4 voting members and $4000 in dues now has <$5 Million – the dues would only be $1,700 and only include 2 voting members

3.2. Or, the organization may have purchased additional voting members and no longer wish to include them in their membership

3.3. Key member must have an interface to determine which voting members to remove

3.4. System should generate email notifications when members are added or removed

3.5. Notify Admin of this type of change to membership

4. When changing Key members, the org joined date is pushed forward to the new key




23

5. When the key member updates their firm it will trickle down to the voting members automatically.

5.1. Use Case: If the organization changes its name from Smith, Inc. to Jones, Inc., all of the voting members’ organizational names would automatically be changed.

6. Key member must be able to maintain the organizational profile

6.1. See the “Profile Fields Map” for additional information on the Organizational Profile

7. Benefactor Level Privileges (in addition to voting members and job posts defined in the “Membership One Pager”)

7.1. Generic login to be provided to the key contact to allow for the benefactors full-time employees to all log into the website with the generic login to access members only documents

7.1.1. Generic login can only be changed by the key contact person or the HL7 Administrators

7.2. Benefactor organizational profile information added to the benefactor areas of the website

7.2.1. Benefactor logo listed on the homepage loop of logo

7.2.2. Listed on the benefactors page

8. Supporter Level Add-on Privileges (in addition to voting members and job posts defined in the “Membership One Pager”)

8.1. Supporter is an add on to any organizational level

8.2. Member must chose a level in addition to Supporter

8.2.1. Cannot choose the Benefactor level

8.3. Doubles the amount of dues for the selected level

8.4. Does not add additional voting members to the selected level

8.5. Overwrites the number of job posts

8.6. Supporter organizational profile information added to the supporter page




24

Events The events system will need to allow for the meeting coordinators to create and manage an event site with full registration capabilities through an easy to use user interface. Members and participants will need to be able to register for the event and its functions and then pay through the website. All users will have to set up a profile before they can register for an event.

Event Types 1. Working Group Meeting

1.1. Survey options

1.2. I am/ an

1.3. Student information

1.4. Weekly options

1.5. Per day fees/options

1.6. Sunday meeting fees

1.7. Meal requirements

1.8. Friday lunch option

1.9. Extra function choices

1.10. Certification test only choice

1.11. Tutorial choices

2. Plenary WGM

2.1. Same requirements as WGM plus:

2.1.1. Check box for length of time individual has been a member of HL7

2.1.2. Page showing the schedule of events for the day of the plenary session

3. Educational Summit

3.1. Survey options

3.2. I am/an

3.3. Student information

3.4. Per day choices

3.5. Two day choices

3.6. Three day choices

3.7. Certification test only choice

4. Harmonization

4.1. Survey options

4.2. Days attending

4.3. Lunch options (whether or not you will be having lunch on specific days)

4.4. Co-chair information

5. Affiliate Events

5.1. Info page

5.2. Optional simple registration and credit card processing

6. Out-of-cycle Meeting




25

7. Info page

7.1. Optional simple registration and credit card processing

8. Co-sponsored Event

8.1. Simple registration form, optional credit card processing

Event Administration 1. Events should be easily administered by a non-technical user

2. Interface should validate the users’ entries to ensure they are logical

2.1. Tutorials should fit within the event dates/times

2.2. Variables and entries should be clearly and logically labeled and organized

2.3. Spell check on all items

2.4. Ability to configure the sort order of items by date or by description

Event Setup 1. Calendar entry

1.1. Event should appear on the global calendar along with a link to the registration

1.2. User should be able to add the item to their Outlook Calendar

2. Registration Dates

2.1. All dates should end at midnight U.S. Eastern time

2.1.1. This should be configurable

2.2. Registration start date

2.2.1. The registration should not appear until this date

2.3. Early Bird end date

2.3.1. Registrations before this date should receive the early bird rates

2.4. Registration end date

2.4.1. Registration should close at this date and the user should see a message to let them know that registration is closed

2.5. Cannot edit after

2.5.1. The user can no longer edit their registrations after

2.6. Cannot cancel after

2.6.1. The user can no longer cancel their registration after

3. Event Dates

3.1. Event start date

3.2. Event end date

4. Registration Items

4.1. Event days

4.1.1. Each day should have a configurable lunch option

4.1.1.1. Lunches may or may not have a cost associated with it

4.2. Event Fee Categories

4.2.1. Each item will need to have the following price categories based on the membership status and date of the registration

4.2.1.1. Member – Early Bird




26

4.2.1.2. Non-Member – Early Bird

4.2.1.3. Member

4.2.1.4. Non-Member

4.3. Event Registration Fees

4.3.1. Per Day Fees

4.3.2. Multi-day packages

4.4. Tutorials

4.4.1. Ability to sort by dates, titles or times when editing

4.4.2. Active

4.4.2.1. Inactive tutorials are canceled and should not appear on registration form for new registrants

4.4.3. Date

4.4.4. Start Time

4.4.5. End Time

4.4.6. Cost

4.4.7. Title

4.4.8. Track

4.4.9. Tutorial Code

4.4.10. Accounting Code

4.5. Event Functions

4.5.1. Use Cases:

4.5.1.1. Networking reception

4.5.1.2. Various dinners

4.5.1.3. Meetings

5. Survey

5.1. Ability to add checkboxes to the registration that when checked will give the member predefined discounts

5.2. I am an/a list

5.2.1. Board Member

5.2.1.1. Free registration

5.2.1.2. One free tutorial

5.2.1.3. Should default to checked if the user is a board member

5.2.2. Affiliate Chair


5.2.2.2. Should default to checked if the user is an Affiliate Chair

5.2.3. MnM Facilitator

5.2.3.1. Free vocabulary tutorial

5.2.3.2. Should default to checked if the user is an MnM Facilitator

5.2.4. Publishing Facilitator


5.2.4.2. Should default to checked if the user is a Publishing Facilitator

5.2.5. Vocabulary Facilitator




27


5.2.5.2. Should default to checked if the user is a Vocabulary Facilitator

5.2.6. First-Time Attendee

5.2.7. HL7 Work Group Co-Chair

5.2.7.1. Should default to checked if the user is a Co-chair

5.2.8. Past Board Chair


5.2.8.2. Should default to checked if the user was a previous board chair

5.2.9. Tutorial Speaker


5.2.9.2. Should default to checked if the user is marked as a tutorial speaker within the event

5.2.10. Staff


5.2.10.2. Free Tutorials

5.2.11. Track Leaders

5.2.11.1. Free tutorials only for those that are listed in their specific track.

5.2.12. Ability to add additional checkboxes with discounts for registration

5.2.12.1. Percentage off

5.2.12.2. Dollar Off


6. Event Sponsors

6.1. Sponsored item

6.2. Sponsor photo

6.3. Sponsor name

6.4. Sponsor link

7. Style sheet

7.1. Configure the coloration of the event to match the brochure

7.2. Event image(s)

8. Documents that can accompany an event

8.1. Use Cases:

8.1.1. Agenda, Brochure, Onsite Schedule, presentations, minutes, etc…

9. An event should contain configurable informational pages 9.1. Cover Page

9.2. Letter from the Chair

9.3. General Info

9.3.1. Explanation of HL7

9.3.2. Explanation of Meetings

9.3.3. Registration instructions

9.3.4. Hotel Information

9.3.5. Travel Information

9.4. Tutorial Information page




28

9.4.1. List all of the tutorials with dates and times

Registration Please see the “Screen Shots” for a visual representation of how this works in the current system.

1. System should know if the user is already registered and should prevent them from registering again

1.1. Give them an option of editing their registration (as specified in the Post Registration section) or printing a receipt

2. Registration Types

2.1. Member

2.2. Non-Member

2.2.1. If a user is not a member, they should be given the option of specifying an affiliate or affiliate organization that they belong to from a list. Selecting any one of these should give them the member rates on anything.

2.2.1.1. Current Organizational Member Firms

2.2.1.2. Current HL7 Affiliates

2.2.1.3. Current MOU Agreements

2.3. Student

2.3.1. Students get 50% off their registration and tutorials

2.3.2. Must have a school and student ID entered into their profile

3. Profile

3.1. Pull from profile

3.1.1. First Name

3.1.2. Last Name

3.1.3. Title

3.1.4. Organization

3.1.5. Address

3.1.6. City / State / Postal

3.1.7. Country

3.1.8. Phone

3.1.9. Fax

3.1.10. Email

3.1.11. Nickname

3.1.12. Meal Preference

3.1.12.1. Saved in profile after registration

3.2. Provide the member a link to edit their profile, but they cannot update their information from this screen with the exception of Nickname and Meal preference

4. Conflict checking

4.1. Don’t allow the user to select tutorials that overlap in date or time

4.1.1. Use case

4.1.1.1. User cannot register for 2 tutorials that start on Monday at 9 AM




29

4.2. Don’t allow the user to register for tutorials and events that are on days that they did not register for

4.2.1. Use case

4.2.1.1. User cannot register for a Sunday meeting if they did not register for Sunday

4.2.1.2. User cannot register for the Networking Reception if they are not registered for the day that it occurs on

Confirmation 1. Total all of the items and discounts for the user to see how they will be charged and

discounted

2. Show non-members what they would save if they were a member

3. Payment Options

3.1. Transactions totaling $0 should not require payment

3.1.1. Use Cases

3.1.1.1. Staff registers

3.1.1.2. A Board member registers for just the event dates

3.2. Credit Card instant transaction

3.3. Credit Card/Check fax/mail-in option

3.3.1. Allow the member to print out the form

Post Registration 1. All data should be stored in a database where it can be reviewed and reported on via the

admin interface

2. Give the user a unique confirmation number

3. Allow the user to print a receipt showing what they registered for, their total, date and time, confirmation number

4. Email notification to the user and staff to alert them of a new registration

4.1. Email should contain all of the registration information as per the current system. See the “Email Sample” documentation for event email samples.

5. Users should be able to edit their registration up until the “Cannot edit after” date

5.1. Items they can change

5.1.1. Name

5.1.2. Survey Info

5.1.3. Tutorials

5.1.4. Meal Preference

5.1.5. Additional Functions attending

5.1.6. Days attending

5.2. Early bird considerations

5.2.1.1. Charges will reflect time of cancellation

5.2.1.2. If you add a tutorial after early bird registration, the cost of the course would reflect the cost at the time of addition

5.2.2. Must validate their changes for conflicts as occurs upon registration




30

6. Users should be able to cancel their registration up until the “Cannot cancel after” date

6.1. Prepaid registrants who cancel prior to Early Bird cut off will receive a full refund minus a $50 processing fee

6.2. After the Early Bird date no refunds will be given

6.3. Tutorials that do not meet minimum attendance requirements may be cancelled. In this event, registrants may attend an alternate tutorial of their choosing or request a refund for the cancelled tutorial only

Reporting Please see the “Report Samples” for examples of the reports.

1. Number of registrants

2. Lunches

3. Registrants per tutorial

4. Registrants per day

5. Registrants by country

6. First Time Attendees

7. Numbers for individual meetings (would like this to correspond with Event Functions)

8. Sort by Registrants email address

9. Comp Lists

10. Registrants by meals per day and meal preference

Meeting Room Request Form 1. Need one form for each Working Group Meeting

2. Must be able to be setup by the event coordinators without help of developer

3. Must be set up months before the event site will be created

4. Only co-chairs or staff can make requests

5. Users cannot submit more than one request for a committee

6. User should only see their own request, not what others have requested

7. User cannot modify their request once it has been submitted

8. Upon submission, notify the user and the event coordinator via email

9. Entry fields

9.1. Work Group

9.1.1. Required

9.1.2. Drop down list of Work Groups

9.2. Requester

9.2.1. Required

9.2.2. Default to the name of the person logged in

9.3. Requestor Email

9.3.1. Required

9.3.2. Default to the email address of the person logged in

9.4. Co-chairs

9.4.1. Multiple co-chair entries

9.4.2. Values




31

9.4.2.1. Co-chair name

9.4.2.2. Co-chair email address

9.5. Number of Attendees

9.5.1. Required

9.6. AV Requirements

9.6.1. Required

9.6.2. Values

9.6.2.1. LCD Projector/Screen

9.6.2.2. Flipchart/pens

9.6.2.3. None

9.6.2.4. Other (describe)

9.7. Entry for each quarter (Q1 - Q4 and evening) and each day of the event (Sunday – Friday)

9.7.1. Needs to be displayed in a logical format such as a matrix

9.7.2. Need option to block certain items

9.7.2.1. For plenary meetings, cannot schedule Monday Q1 or Q2

9.7.3. Within each entry, need to specify Meeting or Host

9.7.3.1. In the case of Host, entry field for groups hosting

Error Handling

Site wide error handler to trap errors

1. User should receive an error notification message (“We’re sorry…”)

2. Email webmaster with error details