HCP registration and validation on your events

Long after an event closes, your compliance and field teams still ask three questions of it. Who was actually there, what did each person consent to, and which healthcare professional (HCP) is each registrant in your CRM? Registration and validation answer them. This guide covers the registration journeys per registrant type, registering on behalf of an HCP, HCP identity resolution, consent capture, and attendance attestation. These capabilities are part of the event platform's registration foundation. They run on every event with a registration journey. The strategic meetings management modules documented alongside this article read the states they produce.

Registration journeys per registrant type

Registration is configured on the event's workspace in Backstage, and three approaches cover the audiences an event program has.

Public (open) registration serves an audience you do not know in advance. Anyone with the link registers, and you control access with email-domain rules, a manual approval step, and capacity limits with waitlisting.

Private (RSVP) registration serves a known, invited list. Attendees are invited by email, and only the invitation link reaches the registration form.

The two combined serve one event with both audiences, for example invited faculty beside open virtual seats.

Each journey is shown end to end in the registration overview.

The journey branches by who is registering.

The registration types offered on an event's form come from your organization's registrant-type list, covering healthcare professionals, internal staff, and agency registrants. That is one list under two names, as documented in How to manage transfer of value on your events.

Each type carries its own journey. The main form collects what every registrant provides, and additional forms appear conditionally on the answers given. An HCP is asked for their institution and specialty, while your own staff are not. The consents presented follow the type on the same rule. A manual approval step holds a type's registrations for review where your process needs one.

On the request side, this pairs with dual status tracking. Where the event came in through a meeting request, that event's registration status and the request status are separate fields on one record. Both are visible in the requester's history, as documented in How to set up and use meeting requests and approvals.

Registering on behalf of an HCP

Not every HCP opens a registration link themselves, so registration does not depend on it. A representative, a congress contact, or an agency registers HCPs on their behalf. The registration lands against the HCP's own identity. The attendee receives the confirmation at their own address. The record carries full traceability, showing who registered whom and when, so an on-behalf registration reads distinctly from a self-registration whenever anyone asks. Agency registrants work inside the access your organization grants them, bounded by scope and workspace membership. See Role-based access and visibility for internal and external stakeholders.

HCP identity resolution

A registrant is a person; your CRM needs to know which person.

Registrants and leads resolve to one master HCP identity. That identity is keyed on the identifiers your organization runs on, such as a Veeva ID, an IQVIA OneKey ID, or an NPI number. The resolution runs across CRM instances and non-CRM sources alike.

At registration, the search runs when the registrant submits the form.

Nothing in the resolution blocks the registration itself.

The connected source is yours to choose. It can be an MDM, a CRM such as Veeva CRM, Vault CRM, or Salesforce CRM, or a reference database such as Veeva Network, Veeva OpenData, IQVIA OneKey, or NPI. The same resolution runs at congress capture, where representatives complete a captured lead's profile on the spot.

Resolved identities are what keep the downstream records clean. The engagement your events capture, and the consent and attendance states below, land against one identity rather than against duplicate profiles. See the Veeva integration and the CRM as the HCP master pattern in Integration patterns: connecting Onomi to your enterprise systems.

Connecting registration to your identity source is an implementation project scoped with your SpotMe team. Please contact your SpotMe Account Manager.

Consent capture

Where consent is the lawful basis your organization defines, it is captured on the registration journey, in your wording. The documented pattern is a required consent checkbox on the registration form, carrying your text and your privacy policy link. Consent is therefore explicit rather than buried, bundled with other options, or assumed by default (see managing legal documents). For in-person capture, a signature pad collects the attendee's signature on the same terms.

What the platform records is the capture. The capture is immutable, timestamped, and tied to the wording version presented. That version is the consent text the registrant saw. The record shows who consented, to which wording, and when.

A capture is never edited in place. A change of consent is a new capture that supersedes the earlier one, and both stay on the attendee in order.

The state the capture produces takes one of three values, and the set is closed:

• Consent captured, where a consent is recorded and in force for that person;
• Consent declined, where the person was asked and declined;
• and No consent recorded, where your organization holds none for them.

Those three values are what a receiving system maps, and there are no others.

The captured record reads on the healthcare professional's own record in Onomi 360, in the profile details, as an ordinary field group:

• the consent state;
• the wording version it was given against;
• the capture source, meaning the form it was captured on and the event that form belonged to;
• the capture timestamp;
• and a link that opens the consent record itself.

That is the one place it reads.

Two absences are deliberate.

Consent is not on the engagement timeline of the record. That timeline is a history of interactions rather than of permissions. Consent is not on any transfer-of-value or financial surface either, because an allocation is a record of money the event spent. An allocation has never been gated by a consent state. The note in Before you allocate in Running and correcting an allocation says so.

The healthcare professional's record itself is documented in How to use Onomi 360: the portfolio calendar, engagement view, and reports.

The boundary matters as much as the capture. The platform records the capture and feeds the consent state to your consent management system or CRM. That system stays the consent master. Inside the platform, the state does one job beyond being read. It gates the engagement data your events capture in a workspace as it syncs to your CRM, rather than the whole of that sync. See the Data privacy guide and the CRM as the HCP master pattern in Integration patterns: connecting Onomi to your enterprise systems.

Attendance attestation

Attendance is captured, attested, and reported per attendee. On an event with a workspace, capture runs at the venue and in the app. Event check-in and badge printing records who arrived, and session check-ins record who sat where. The criteria that turn those signals into an attendance status are configurable, and you download the attendance report from Backstage. Where your compliance process asks for an attestation rather than a scan, the signature pad collects the attendee's signature at check-in. The signature is securely stored for verification.

Per attendee, the state your strategic meetings management records read is Show, No-show, or No state recorded. That set is published in the attendance check in Before you allocate in Running and correcting an allocation. On a meeting run without a workspace, the state is recorded directly on the event record, as that guide documents.

You read it per attendee in Onomi 360, on the Review tab of the event's Transfer of value module, alongside the identity state above.

The show and no-show states also go back to the field. The meeting record and its attendees reach your CRM on the connector's meeting record sync. Each attendee carries the attendance state recorded on them. The team preparing the next interaction reads who showed and who did not, where they already work.

The states carry financial consequences. Only attendees recorded present carry allocated amounts, which is why the attendance record is among the checks run before an allocation.

* Onomi 360 MeetingsEQ exclusive capabilities.