CHG Healthcare runs two provider credentialing applications — one for physicians placed through its CompHealth and Weatherby Healthcare staffing brands, another for allied health providers — being unified into a single schema-driven system, built and configured through Modio, the editor CHG's credentialing team uses to define its forms.
Each application was built separately, at a different time, for a different audience. Neither shared an underlying data structure with the other — which meant every future improvement would have to be built twice, or the team would first have to work out how one schema could serve both, configured inside Modio, the editor the team builds its forms in.
An 18-page credentialing application used by CHG's staffing brands, CompHealth and Weatherby Healthcare, to place physicians on locum tenens assignments.
A 16-page application for allied health providers — nurse practitioners, physician assistants, registered nurses, and other non-physician roles — with its own section structure.
The first deliverable wasn't a wireframe — it was a complete field-level audit of all 20 sections across the two applications, benchmarked against how each field would behave once configured inside Modio, the editor. Every row was classified with a badge system so engineering and product could see, at a glance, what was shared, what was unique to each application, and what still had no decision.
| Field | Badge | CHG Physician | In Modio (the Editor) |
|---|---|---|---|
| Primary Specialty | Decision needed | Dynamically controls the Clinical Capabilities page | No equivalent — the editor isn't specialty-aware |
| NPI Number | Differs | Open text | The editor validates in real time against the NPPES registry |
| Smart entity lookup | Decision needed | Not present | The editor offers predictive lookup from NPPES, ACGME & AHA hospital directories |
| CAQH section | Native to the editor | Not present | Provider ID, attestation dates, account status |
Comparing field-by-field, instead of designing directly on top of assumptions, surfaced problems a surface-level redesign would have missed.
The Allied application actually covers at least two distinct provider groups — Cota/EEG Tech/Physical Therapy versus Nurse Practitioner/Physician Assistant/Psychology — with different depth in Education, attestations, and professional liability. That wasn't visible until the fields were compared one by one.
Selecting the Primary Specialty dynamically controls which clinical questions appear later. It's the most foundational decision in the whole project — and it can't be added later without a schema rebuild.
Legal flagged that an external data provider's contract prohibits sharing data directly with third parties — meaning auto-enrichment inside the editor needed legal review before it was built, not after.
The answer to "how does one schema serve two different applications, built through the same editor" was a two-tier configurability model. Every form field is classified as either locked or configurable, and that classification — not the individual screen — is the real design system behind the platform.
Cannot be removed by either child template. NPI, DEA, malpractice questions, attestation and signature. Renders identically no matter which application shows it.
Fields each application can toggle, relabel, or adjust — Medical Training, the Life Support certification list, Professional Organizations — depending on how they're configured inside the editor.
Every decision was framed as a clear choice with options, each one's impact, and a team recommendation — organized from the most architecturally critical (blocks schema design) to the most tactical (copy and microcontent).
Chosen: routing. Higher Phase 1 complexity, but delivers CHG's core value proposition and can't be added later without a schema rebuild.
Chosen: full smart lookup. Predictive lookup of schools, hospitals, and employers against NPPES, ACGME, and AHA directories, cutting redundant provider data entry.
Chosen: legal review in parallel. A third-party data contract limited how enrichment could be used once configured inside the editor. Rather than block Phase 1, legal review runs in parallel while the rest of the schema keeps moving.
Chosen: sub-templates by provider type. An audit finding, not an original requirement — the Allied child template branches by provider type instead of using one form for everyone.
This wasn't a consumer product flow where a confusing field can just be cut. It was a regulatory application shared across product, engineering, legal, and credentialing operations teams, each with their own reason not to budge.
Tier 1 fields — NPI, DEA, malpractice questions, attestation — are mandatory no matter which child template renders them. No design decision could touch them.
A CV auto-extraction pipeline was already in active engineering development in parallel. The new platform had to plug into that pipeline's event schema, rather than design in isolation.
Product, engineering, legal, and credentialing operations all had to agree before wireframe design could start — and architecture decisions had to be resolved first because they're the most expensive to reverse once development begins.
The audit and decision brief became the shared reference between product, engineering, legal, and credentialing operations — unblocking wireframe and schema design while keeping compliance-critical fields untouched across every child template.