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 explains 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 use the states they produce.

Registration journeys per registrant type

You set up registration 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 can 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 opens the registration form.

You can serve one event with both audiences by running the two combined, for example invited faculty beside open virtual seats.

The registration overview shows each journey end to end.

The journey branches by who is registering.

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

Each type has 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.

You can hold a type's registrations for review with a manual approval step, if your process needs one.

On the request side, this pairs with dual status tracking.

If 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 keeps full traceability, showing who registered whom and when, so you can tell an on-behalf registration 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 your organization's choice. 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, not against duplicate profiles.

See the Veeva integration and Connecting CRM, HCP identity, and consent.

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

Consent capture

If consent is the lawful basis your organization defines, you capture it on the registration journey, in your wording.

The documented pattern is a required consent checkbox on the registration form, with your text and your privacy policy link.

Consent is therefore explicit: not buried, not bundled with other options, and not assumed by default (see managing legal documents).

For in-person capture, a signature pad collects the attendee's signature on the same terms.

Your consent-management platform, master data management system, or CRM remains the system of record for consent. Onomi 360 reads the current consent status or reference from that connected source and shows it on the HCP profile.

If an Onomi event captures consent during registration or check-in, the capture records the person's response, the wording presented, and the time of capture. Onomi sends that capture to the connected system of record. That system controls the consent lifecycle, including later changes, withdrawal, and retention.

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

• Consent captured, when a consent is recorded and in force for that person;
• Consent declined, when the person was asked and declined;
• and No consent recorded, when your organization has no consent on record for them.

Those three values are what the connected systems map, and there are no others.

You can read the synchronized consent information on the healthcare professional's own record in Onomi 360, in the profile details:

• the consent state;
• the wording version, if the source provides it;
• the source system or event capture;
• the capture or last-updated timestamp, if the source provides it;
• and the source record reference, if the connection provides one.

The profile is the one place that shows it.

Two absences are deliberate.

Consent is not on the engagement timeline of the record. That timeline is a history of interactions, not 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. Onomi can capture consent during an event and can show the synchronized status on the HCP profile. It does not replace your consent-management platform, master data management system, or CRM as 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 that data syncs to your CRM, not the whole of that sync.

See the Data privacy guide and Connecting CRM, HCP identity, and consent.

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 can download the attendance report from Backstage.

If your compliance process asks for a signed attestation and a scan is not enough, 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 rely on 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 can 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 arrive in your CRM on the connector's meeting record sync. Each attendee row includes the attendance state recorded on them.

The team preparing the next interaction sees who showed and who did not, in the system they already work in.

The states have financial consequences. The allocation attributes amounts only to attendees recorded present, which is why the attendance record is among the checks run before an allocation.

* Onomi 360 MeetingsEQ exclusive capabilities.