CME Registration & Credit Management

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "registration" and "activity" because that is what a provider says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The disclosure is collected on a form that is not the registration form

The Standards for Integrity and Independence oblige you to hold a relevant-financial-relationship disclosure for the people involved in an activity, and the usual way it gets held is a separate survey link, sent afterwards, to a physician whose inbox is competing with a clinic list. Some answer in the first week. The rest get chased by whoever runs the CME office, twice, and a few never answer at all — which nobody notices until the file is being assembled for a reaccreditation visit and the registration list and the disclosure list turn out to be two different documents that have to be matched on a name spelled two ways. The question is not the hard part. The hard part is that the one moment the participant was definitely paying attention has already gone.

What bindro does: Disclosure is a required field on the registration itself, so there is no paid registration with a gap in it and nothing to chase — the refusal happens on the money path rather than in a reminder. It is asked per participant rather than per order, which is the detail that matters on a department booking: eight places collect eight answers, and a place filled in later by the physician taking it collects theirs at that point instead of inheriting the co-ordinator's. A follow-up detail box can be made conditional on the answer and the rule is evaluated on the server as well as in the page, so a hidden question is genuinely not required rather than merely invisible. What bindro does not do is read it: nothing scores a disclosure, nothing blocks a registration on its content, and the review your accreditation requires of you stays exactly where it is today.

Licence copies arrive as photographs, in eleven separate email threads

A licence copy is the least interesting document in the CME office and the one that takes the most handling. It arrives as a phone photograph attached to a reply to a confirmation email, or forwarded by a departmental administrator on behalf of four people, or not at all until somebody asks a third time. Then it has to be filed somewhere it can be found again, which in practice means a shared drive with a folder per activity and a naming convention only one person actually follows. The quiet risk is not the missing file; it is the mailbox itself, because a licence photograph sitting in a general inbox is personal documentation held somewhere nobody chose and nobody reviews.

What bindro does: The licence copy is an upload on the booking, required before the order can confirm, and it is claimed onto the order at the moment payment is taken. A reference that does not resolve to that booking's own upload is refused on the money path — you cannot attach somebody else's document to your registration, and an invented reference does not confirm an order. Documents are held per registration with a size limit and downloaded from the console roster by staff whose role allows it, which is checked in the handler rather than by hiding a button. Because the field is order-scope, the control renders once per booking rather than once per person, so a department uploading for a block does it once and not eight times.

Nothing proves who was in the breakout room at two o'clock

The plenary is easy to evidence and the concurrent sessions are not. A clipboard per room is signed by the people who arrive early, passed down a row by the people who do not, and collected at the end of the day by whoever is nearest the door. What it records is that somebody wrote a name at some point in a building — not which of the four parallel workshops they sat, not that they stayed past the coffee break, and not legibly enough to reconcile against a registration list a year later. The exposure is asymmetric too. The physician claiming the hours is not the one who has to produce the evidence; the accredited provider is, and by the time anyone asks, the person who staffed that room has moved to another department and the sheets are in a box.

What bindro does: Each session is scanned on its own. A badge is scoped to the sessions it was registered for, so a participant admitted to the morning plenary is simply unknown at the afternoon workshop they did not register for, and every scan is written against that session rather than against the day. A delegate stepping out of a room and back in through the same door is readmitted as a re-entry, and the attendance is counted once however many times a badge is presented or a phone is handed over. What you hold afterwards is not a sheet somebody has to interpret but a per-session attendance record with a time on it, and that record is what credit is then derived from. Nobody reconciles anything at the end, because the reconciliation is the door.

Certificates are a week of mail merge and then a year of re-sends

The merge is the visible cost: a spreadsheet of names against hours, a template, a serial column somebody increments by hand, and two evenings of sending. The invisible cost is the eleven months afterwards, because a CME certificate is the one document a physician loses and then needs urgently, usually a fortnight before a licence renewal or a board deadline. Every re-send is a person opening the spreadsheet again and deciding whether to reuse the old serial or mint a new one — and a second serial for the same hours is precisely the thing that makes a record look manipulated when it is only untidy. The worst version is a certificate issued to somebody who paid, was on the list, and never came, because there was never anything in the process that could tell the difference.

What bindro does: Issuing is one action per session, taken after that session has ended. Bindro writes one credit per verified attendee carrying that session's contact hours — computed from its own start and end times rather than typed — and a unique serial, and each certificate is a page addressed by that serial, so it can be verified by quoting the serial alone. Issuing again for the same session is idempotent: it fills in anybody who was missed and never mints a second credit for a physician who already has one, which makes a re-run safe rather than something to be nervous about. A session that has not ended yet is refused outright, so there is no route to issuing credit for a room that has not happened. And a registrant who never scanned in gets nothing — the case the mail merge could not see is the one the door answers for free.

The department has a purchase order and the finance office has no card

A division chief wants eight of their fellows on the regional conference and forwards you to a purchase order, terms of thirty days and an accounts payable portal. The registration platform wants a card number. So the places get held on trust in a spreadsheet, the invoice goes out of an accounting package that knows nothing about the activity, and the reconciliation between the two lives in one person's memory until they take annual leave. The failure is rarely a hospital that refuses to pay. It is an activity that ran with eight places nobody ever billed for, discovered in a quarter-end that was already busy, and a set of names on the door list that no order in the system explains.

What bindro does: The checkout offers to invoice the organisation, and an invoiced registration confirms with no card at all. Bindro issues a numbered bill carrying the department's own purchase order reference and your standard terms, commits the places immediately, sends the bill to accounts payable and the badges to whoever booked. The accounting is the careful part: issuing an invoice writes no ledger entry whatsoever, so your balance cannot carry places nobody has paid for and a payout can never be funded by an outstanding bill. Somebody with finance rights records the settlement when the remittance lands, recording it twice is refused, and an invoice that passes its due date unpaid is voided automatically with the places returned to sale rather than held indefinitely for a department that changed its mind.

The registration desk has twelve minutes and the ballroom has no signal

Registration for a regional conference happens in about twelve minutes, in a corridor, in front of two hundred physicians who all have somewhere to be at eight. That is the moment a hotel guest network decides it wants a room number, or the ballroom turns out to sit under the one dead spot on the floor, or the conference centre's wifi is genuinely fine and simply cannot carry the load of everyone arriving at once. What happens next is always the same: the tablets go away, the printed list comes out, and the per-session attendance record — the entire reason the scanning existed — becomes ticks in biro that somebody types up the following week from memory and a coffee-stained page.

What bindro does: The desk expects no signal, because that is the real situation rather than a degraded version of it. Each device syncs a signed manifest of who is expected at that session before the doors open, validates badges locally with no network call at all, and uploads its shift log when it can; replaying that log applies it exactly once however many times it is uploaded. Where a badge cannot be produced, a name can be found on the same screen and admitted by hand. Run several doors for concurrent sessions and a clash — the same badge scanned in two rooms at once — lands in a conflict queue for a person to look at instead of the system silently picking a winner. Two honest limits: an offline count is only as fresh as its last sync, and live remaining capacity comes back when the device is back on the network.

Credit issued from the scan, never from the payment

This is the capability the vertical is built around, and it is one sentence long: attendance is captured per session at the door, and credit is issued from those records afterwards. The chain from a badge scan to a serialised certificate is short enough to explain to a reviewer in a single breath, which is the property that matters when somebody is assessing how you document an activity.

• Contact hours come from the session's own start and end times, so a certificate cannot disagree with the programme that was delivered.
• One credit per physician per session, carrying a unique serial that verifies the certificate on its own.
• Re-issuing a session is idempotent — it picks up anyone who was missed and never mints a second credit for somebody who already has one.
• A session that has not ended is refused: there is no path to credit for a room that has not happened yet.
• A comped place earns credit identically, because the credit follows the scan and not the money.

The licence and the disclosure collected before the money moves

The registration form for this vertical arrives configured for accredited education rather than assembled by you from a blank page, and the mandated fields render locked so they cannot quietly be removed by whoever builds next year's activity. The material your accreditation obliges you to hold is collected at the one moment the participant is definitely paying attention: on the way to paying.

• NPI or licence number and employer, a licence copy uploaded against the order, and a financial disclosure per participant.
• Society membership number where a member rate applies, plus dietary and accessibility answers for the catering and the room.
• Conditional follow-ups are enforced on the server, so a question a rule hides is genuinely not required and a hand-posted answer to an invisible field is refused.
• Unknown answer keys are rejected at validation rather than stored, so nothing lands in an unaudited column.
• Nothing here assesses a disclosure: no score, no rule, no mitigation workflow, and no faculty population modelled separately from participants.

A badge that is also the credential at every door

Badges are this vertical's primary door credential rather than a printing convenience, so the thing that identifies somebody in a corridor is the same thing that admits them to the workshop they registered for. Every participant on the roster has a printable badge page carrying their name, the activity and their registration type, laid out for print rather than for a screen.

• Badges are scanned per session, and a badge presented at a session it was not registered for reads as unknown rather than being waved through.
• A delegate coming back into a room through the door that scanned them in is readmitted as a re-entry, with the time they first arrived; the same badge at a different door reads as already used. The attendance is recorded once either way.
• Multiple door points run at once for concurrent sessions, and clashes across them queue for review instead of resolving themselves silently.
• The desk works with no signal at all and reconciles when it reconnects; live remaining capacity per session returns with the network.
• Walk-ups and telephone registrations go through the back office onto the same roster, the same place pool and the same credit run.

Society member rates your own roster decides

For a specialty society the member price is not a promotion, it is the membership benefit — a substantial part of why a subscription gets renewed. Running it as a discount code hands that benefit to whoever forwards the email, and the leak stays invisible until somebody totals the year. Here the member rate is a property of the registration type and the membership reference is verified on the money path.

• A current member is charged the member rate; a lapsed or revoked reference is refused against that field before the money moves rather than argued about afterwards.
• Only a one-way digest of the reference is stored: the console can show a name and whether the membership is current, and can never read the number back.
• The order line records why a place was cheaper, so the member against non-member split is a query rather than an archaeology exercise.
• Early rates and tiered registration types run alongside it, which is how most conferences actually sell.
• Promo codes exist for what pricing does not cover — a faculty member's institution, a reciprocal arrangement with another society.
• There is no separate group price to set and no annual all-access pass; both are explained rather than quietly absent.

Departments book blocks and name the physicians afterwards

A hospital department buys CME the way a hospital department buys everything: one order, several places, and the names arriving late — a forwarded email at nine the night before with seven names and one still to confirm. That is the normal case here rather than the awkward one, so the roster is built to expect it instead of being surprised by it.

• The order pays for the places up front and the roster is filled in later, either by typing names or by emailing each place to the physician taking it.
• Filling a roster renames places the order already bought — it never creates inventory, so a block cannot quietly grow past what was paid for.
• An unnamed place stays off the door list and is refused at the scanner, so it cannot become an attendance record with nobody's name on it.
• Registration answers are collected per physician: their own NPI, their own employer and their own disclosure, not one set for the whole department.
• Each named physician gets their own badge, their own scan record and their own certificate.
• A block is priced from the published member and non-member rates, because there is no separate group price a provider can configure.

A grant and board report that agrees with the ledger to the cent

CME offices report upwards more often than most organisers: to a board, to a department, and to whoever funded the activity. The report is normally rebuilt each quarter from a registration export, a finance extract and somebody's recollection of how many places were comped. Here it is one page, generated from the same records everything else on the platform is generated from.

• Activity and income by quarter: sessions delivered, registrations taken, participants attended and free places given.
• Gross, refunded and net income read from the ledger the payouts reconcile against, so the report and the finance page cannot disagree.
• Downloadable as CSV and laid out to print as a board pack, so the version that goes in the papers is not a screenshot.
• It is a report for your board and your funders. It is not a PARS submission, and nothing in it is transmitted anywhere.
• It carries no demographic breakdown, because this vertical asks no demographic questions — a gap you can see rather than a section that looks broken.

Sponsors on the roster, and no sponsor money in the system

Commercial support is where a CME landing page normally overclaims, so this one is blunt about the boundary. You can define sponsor packages and record which supporters took which, so the roster and your on-site staff know who is in the building and at what tier. No money moves through bindro for any of it, and that is a design decision rather than a missing screen.

• Recording a sponsor sale changes the roster and never financial truth: no charge is taken, no ledger entry is written, no platform fee applies and nothing is paid out.
• You invoice the supporter off-platform, which is where the separation of commercial support puts that money anyway.
• There is no exhibit-hall floor plan and no bookable booth inventory: booth booking is not part of this vertical at all.
• A sponsor package is therefore a record of an agreement you made elsewhere — useful on site, and worthless as a revenue figure.

Who pays the booking fee?

The participant, unless you say otherwise. Every activity carries its own setting — the participant pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-registration $25.00 activity that is $16.20 either added to what participants pay or taken out of what you keep.

Because the default is the participant, a provider can go from signing up to a sold-out activity without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by activity, admits one only once its LAST session has ended, and pays it once. An activity sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on activities that have not happened is exactly how a cancellation becomes participants with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per activity, after its last session ends, one in flight at a time.
• T+2 for this vertical (medium risk tier), with 4.5% held as reserve and released later.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The console shows the two halves of that figure on one page. Every ended session is listed with its contact hours, the count of verified attendees and how many credits have been issued against it, so a session that was scanned but never issued is visible rather than forgotten. The issued certificates sit underneath with their serials, hours and dates, each one linking to the certificate itself. Multiply and add and you have the year — the page is a working list rather than an annual return, so the totalling is a spreadsheet away through the export.

The three numbers this vertical is scored on beside it deserve very different degrees of confidence, and the difference is worth knowing before you build a report on any of them. Session attendance depth is real and comes straight out of the scans: how many of the sessions a participant registered for they were actually admitted to, which is the number that tells you whether the Friday afternoon track is worth running again. Disclosure completion is answered by construction rather than improved over time, because the field is required on the money path and a registration cannot be paid for without it. Sponsor revenue per attendee is the honest hole: no commercial support money moves through bindro, so the numerator is not in the system and no page here will pretend to divide by an attendance count that is.

The segments have the same split. Membership status is genuine, because the price applied to a place is recorded with the reason it was applied. Sponsor tier is a roster record rather than a revenue dimension, for the reason above. Session track is however you structure and name the sessions. Specialty is not collected by default — the form asks for an NPI or licence number, not a board certification — so if the specialty mix is a number your programme committee wants, you add specialty as a registration question and it comes back in the export with everything else.

The console computes a headline figure and prints the arithmetic under it, and the arithmetic is the point: credit hours delivered is attendee-shaped until the credit module records its own units, so the number counts people on delivered activities and the basis line under it says so — a count of physicians is never left to read as a count of hours.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per activity, read from the ledger the payouts reconcile against.
• Registrations sold against participants checked in, with a no-show percentage per session.
• Live remaining capacity while the activity is running, per pool, on the day-of screen.
• This provider's own funnel — view → agenda built → checkout → paid → attended → credit claimed — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and participants as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a provider's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• Reporting activities or credit to PARS — nothing in the engine transmits anything to ACCME, to a specialty board or to any other accreditor. Bindro produces the attendance evidence and the per-session hours behind a submission; the provider makes the submission, exactly as they do today.
• Credit types — a credit record carries hours, a serial and the session it came from. AMA PRA Category 1, MOC points, nursing and pharmacy hours are not modelled as separate kinds, so any split between them has to come from how you structure the sessions.
• Reviewing, scoring or mitigating a disclosure — the disclosure is captured as the participant wrote it and stored against their registration. Nobody at bindro reads it, no rule blocks a registration on its content, and the relevant-financial-relationship review the ACCME Standards require of you happens where it does today.
• Faculty management — planners, presenters and reviewers are not modelled as a separate population with their own disclosure and mitigation workflow. Everyone on the roster is a participant, and faculty records live wherever they live now.
• Collecting commercial support or exhibitor money — sponsor packages and sales are recorded on the roster only. No money moves through bindro for them: no charge is taken, no ledger entry is written, no fee is charged and nothing is paid out. You invoice the supporter off-platform, as the separation of commercial support requires anyway.
• Selling exhibit-hall booths as bookable inventory — booth booking is not declared for CME providers, so there is no floor plan and no pitch to sell; a sponsor package is a record of an agreement you made elsewhere.
• Building an agenda across a multi-day activity in the hosted checkout — the hosted flow sells one session per order today. Multi-session orders ship on the public JSON API, so a conference sold session-by-session through the hosted page needs that route or one order per session.
• Enduring materials, on-demand and journal CME — bindro sells the registration and admits at the door. It hosts no content and keeps no learner record, and a credit here comes from a scan at a live session.
• Annual all-access CME subscriptions — payouts settle per delivered activity, so subscription revenue could be taken and never paid out. It is refused on purpose.
• Paying a registration in instalments, deferring a place to a later run, or adding sales tax — all three are optional for this vertical and none are enabled.
• Handing a registration to a colleague, or a waitlist on a closed activity — neither ticket transfer nor waitlists are declared for CME providers, so a place is refused rather than quietly reassigned, and closed means closed.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

Setting up is the short part, and one decision in it is worth taking slowly. An activity carries its sessions, and each session carries its own capacity and its own door — but a session is also the boundary credit is issued on, so the sensible structure follows the credit rather than the room timetable. A half-day with a coffee break is one session if the hours are one block and two if they are two credits. Getting that right before you publish saves a conversation with a reviewer later, and it is much easier than restructuring an activity people have already registered for.

Registration types go on next: a member rate, a non-member rate, and tiers if an early rate is part of how the conference sells. Selling happens on your own activity page or through the checkout embedded in the site you already have — a society or a hospital nearly always has one, and sending members off it to a platform-branded page is a conversion cost with no upside. Departments take the invoice route, individual physicians pay by card, and anybody who telephones the CME office is registered from the back office onto exactly the same place pool. None of those is a separate ledger or a spreadsheet row.

On the day the tooling is one-handed and standing up. Print the badges, sync the manifests before the doors open, scan each session, admit the walk-ups you take by name where a badge cannot be produced, and do not think about the network. Afterwards, issuing credit for a session is one action that can be repeated safely, the post-activity email goes out on its own, the roster exports as CSV, and the payout arrives two days after the last session ends — one payout for the activity, never before it has been delivered.

• Structure sessions on credit boundaries; capacity, doors and certificates all follow the session.
• Publish a member and a non-member rate rather than a code somebody can forward to a listserv.
• Point departments at the invoice route; it commits the places without touching your balance.
• Print badges and sync each session's manifest before the desk opens, not while a queue is forming.
• Issue credit once a session has ended, and re-run it safely for anyone who was missed.

This is the first question a CME buyer asks, so it is answered on the landing page rather than three clicks into a support article. What bindro produces is the evidence a submission is built from: the sessions you delivered with their contact hours, who was verifiably in each room, a serialised certificate per physician, and the licence and disclosure material collected at registration. You make the submission, exactly as you do today, and you can export everything it needs.

The second half is the one worth being pedantic about, because the phrase is everywhere in this market. Compliance is a property of a provider and a process. A registration system can hold the records that process is assessed against, and claiming more than that on the highest-traffic page of the vertical would lose the argument in the search result before anyone read the honest half. This vertical's own accreditation record is non-blocking by configuration: it is a note against the activity saying the provider reports credit issuance to the accrediting body and that bindro transmits nothing to anyone. It is not a checkbox that certifies something on your behalf.

Some established CME platforms do offer PARS submission as part of what they sell, and if filing on your behalf is a requirement rather than a preference, that is a genuine reason to choose one of them. The comparison pages linked from this page say so plainly instead of burying it — and they ask you to check the competitor's current documentation rather than trusting our summary of it. Bindro is the layer underneath: registration, the compliance material, the money, the door, and the credit record itself.

One related limit belongs in the same breath, because it disappoints people at the same moment. Credit types are not modelled. A credit record carries hours, a serial and the session it came from, so any split between AMA PRA Category 1, MOC points, nursing hours or pharmacy hours has to come from how you structure and label the sessions rather than from a category field the system understands.

The useful property is that none of it was assembled for the review. The attendance record is the door doing its job on the day. The certificate serial is the artefact the physician already has in their inbox. The price applied to a place is on the order line because that is how the money worked, and the disclosure is against the registration because the registration could not be paid for without it. A record built at the time by the system that ran the activity is worth more than a reconstruction, and it is very much faster to produce.

Verification runs in both directions. A physician can be checked against a serial, and a session can be checked against the list of everyone who was scanned into it. Because credit comes from attendance rather than from payment, the two most awkward cases answer themselves: somebody who paid and did not come has no certificate, and somebody who came for the Thursday has the Thursday hours and nothing more. The awkward conversation happens with the physician at the time, which is the right place for it, instead of with a reviewer years later.

Access to all of it is governed by role rather than by who knows the URL, and the roles here are the ones a CME office actually has: a door login sees a name and whether a badge admits, downloading a licence document needs the role that allows it, and recording a settlement against an invoice needs finance rights.

The multi-session limit is the one most likely to affect a real conference, so it deserves exact language. Multi-session orders exist — one order, one line per session, a badge per participant per session that admits at that session only — but they ship on the public JSON API today, while the hosted checkout page still sells one session per order. A three-day conference run entirely through the hosted flow therefore sells each session as its own registration, which works and is more clicks than it should be. This vertical's capacity model is a multi-day agenda, so this is precisely the limit a conference organiser should plan around rather than meet by accident; the conference guide linked from this page walks through what each option looks like in practice.

The subscription refusal is structural rather than a missing screen, and the mechanism explains why no amount of asking will change it. Payouts settle per delivered activity: the scheduler groups by activity, admits one only once its last session has ended, and pays it once. Money taken for a year of unspecified future activities has no delivery event to release it against, so it would sit in a balance the payout engine could never settle. Taking money we could not pay you would be worse than refusing it, so the checkout refuses it — and the same reasoning is why nothing is ever paid out before an activity is delivered.

On the rest, the honest framing is that these are configuration decisions for this vertical rather than permanent verdicts. Instalments would let a physician spread a large conference fee; deferral would let somebody move to next year's run; sales tax matters if your activities are taxable where you are. Each is off, and each is refused at the call with a hard error rather than quietly doing nothing — which is the failure mode that actually hurts, because it looks like it worked.

And one about scope rather than configuration. Bindro sells the registration and admits at the door; it hosts no content and keeps no learner record, so enduring materials, on-demand modules and journal CME are outside it entirely. Credit here comes from a scan at a live session. If half your credit hours are delivered on-demand, you want a learning management system for that half, and the comparison pages will tell you which of the incumbents is one.