IG Stack Compare
Cross-IG dependency pin, overlapping profile, and maturity divergences. Stack is stored in this browser (localStorage). Analysis-only — no sidecar.
← Back to FHIR Analysis WorkbenchPackage Compare (two versions) →
Loading IG catalog…
Spine & drift map — the eight spine pin-set IGs
emitter v1.0.0Computed across the eight IGs in this project’s spine pin-set (a subset of the full IG catalog), at two pin-sets. Five of them are named by CMS-0057-F; HRex and CARIN Blue Button are named by no rule in the register, and CDex is named by CMS-0053-F. Per-concept verdicts and notes are curated; each drift-map entry is tagged curated or computed (the version-axis and HRex-floor entries are machine-derived, not curated). Two hand-sample concepts (Coverage, MedicationRequest) carry a full element-level must-support set-diff; the rest remain base-profile-level (caveat shown per concept).
The versions the prior-auth trio and their foundations resolve to for a 2027-compliance payer. Drift computed against latest would be FALSE drift for that payer (seed doc §2).
Status: COMPLETE · generated 2026-08-14
Ranked drift map
- MedicationRequest: base R4 vs US Core curatedCRD profiles MedicationRequest on base R4; PAS on US Core MedicationRequest. Same resource, same workflow, two different bases — a drug prior-auth valid as CRD input is not automatically valid PAS input. The cleanest single illustration of foundation-choice drift in the trio.
- Coverage is profiled three times curatedCRD Coverage, PAS Coverage, and HRex Coverage are three canonical URLs for the member's insurance — all on base R4 Coverage, each with its own slicing/must-support, none deriving from another.
- Three exchange paradigms, zero shared transport curatedCRD speaks CDS Hooks (cards + systemActions), DTR speaks SDC ($questionnaire-package → QuestionnaireResponse), PAS speaks Claim/$submit (Bundle ⇄ X12 278/275). There is no union of a CDS Hook, a Questionnaire, and an X12-bound Claim — they are stations on a relay, not variants of one thing.
- The Task resource means four different things curatedCRD Task = 'go fill out this form' (SDC-derived, launches DTR). DTR consumes it. PAS Task = 'your auth is pended, watch this Subscription'. HRex Task = generic data request. Four profiles, four intents.
- The US Core fault line — on the version axis computedCOMPUTED (crossClusterPins, replacing the seed doc's [VERIFY] flag): the CMS-cited prior-auth trio + HRex pin US Core 3.1.1 (USCDI v1, 2020), while the payer-data cluster (CARIN Blue Button, PDex, CDex) pins US Core 7.0.0. A payer standing up prior auth on 3.1.1 and another required API on 7.0.0 carries two US Core versions inside one compliance deadline — the cross-cluster fault line a trio-only view can't see.
- HRex 1.0.0 is a moving floor computedThe cited trio pins HRex 1.0.0, which still defines an HRex Practitioner and an HRex ClaimResponse profile — both removed in HRex 1.1.0. Any diff run against current HRex would flag those as 'dropped' and mislead: 'reconcile against latest' is a bug, not a convenience — which is why the artifact computes a cited pin-set, not just catalog defaults.
Canonical spine
| Concept | Verdict | Class | IGs | Notes |
|---|---|---|---|---|
| Patient | aligned | aligned | 6 | Mostly aligned on US Core Patient; PAS splits beneficiary (profile-beneficiary) vs subscriber (profile-subscriber). aligned at the base-profile level, pending element diff |
| Coverage | drift | foundation-choice | 4 | 3 distinct Coverage profiles (CRD, PAS, HRex), 3 canonical URLs, all on base R4 Coverage, none deriving from another — the object at the dead center of prior auth has no single agreed shape. |
| Practitioner | aligned | aligned | 5 | Aligned base (US Core Practitioner), split identity — 2 profiles on US Core; HRex 1.0.0 adds a 3rd (removed upstream in 1.1.0). aligned at the base-profile level, pending element diff |
| PractitionerRole | drift | foundation-choice | 4 | PAS PractitionerRole on base R4; HRex on US Core — different foundation for the same concept. aligned at the base-profile level, pending element diff |
| Organization | aligned | aligned | 6 | Aligned base (US Core Organization); PAS splits insurer vs requestor. aligned at the base-profile level, pending element diff |
| Encounter | aligned | aligned | 3 | Genuine agreement — both on US Core Encounter. Not everything drifts. aligned at the base-profile level, pending element diff |
| Location | aligned | aligned | 3 | Genuine agreement — both on US Core Location. aligned at the base-profile level, pending element diff |
| Task | drift | exchange-paradigm | 4 | Same resource type, four profiles, four intents: CRD Questionnaire Task ('fill out this form'), DTR consumes it, PAS Task ('auth pended, watch this Subscription'), HRex Task (generic data request). An implementer handling 'Task' generically mishandles at least two. aligned at the base-profile level, pending element diff |
| MedicationRequest | drift | foundation-choice | 3 | CRD profiles MedicationRequest on base R4 (CRD's IG note: US Core 'accidentally constrained out PractitionerRole', so they dropped to base R4 'to move to US Core later'); PAS profiles it on US Core MedicationRequest. A drug prior-auth valid as CRD input is not automatically valid PAS input — the cleanest single illustration of foundation-choice drift. |
| ServiceRequest | drift | foundation-choice | 2 | Same resources, different job — CRD annotates coverage on the request; PAS maps it to Claim line items via RequestedService. aligned at the base-profile level, pending element diff |
+ 11 additional shared resource type(s) computed by the set-first sweep (breadth; not curated).
Element-level must-support — hand samples
Full mustSupport path set-diff for the two depth-sampled concepts. Paths marked all are genuine element-level agreement; a shared path across profiles built on different bases is still foundation drift — the ranked verdict above is not erased by element overlap.
Coverage bases differ 4 shared · 8 unique · 22 total
hl7.fhir.us.carin-bb → us-core-coverage (19) · hl7.fhir.us.davinci-crd → Coverage (22) · hl7.fhir.us.davinci-hrex → Coverage (9) · hl7.fhir.us.davinci-pas → Coverage (8)
Coverage.beneficiaryallCoverage.identifierallCoverage.payorallCoverage.subscriberIdallCoverage.classhl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-hrexCoverage.class.namehl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crdCoverage.class.typehl7.fhir.us.davinci-hrexCoverage.class.valuehl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-hrexCoverage.dependenthl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-hrexCoverage.identifier.typehl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crdCoverage.identifier.valuehl7.fhir.us.davinci-hrexCoverage.metahl7.fhir.us.carin-bbCoverage.meta.lastUpdatedhl7.fhir.us.carin-bbCoverage.networkhl7.fhir.us.davinci-crdCoverage.orderhl7.fhir.us.davinci-crdCoverage.periodhl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crdCoverage.policyHolderhl7.fhir.us.davinci-crdCoverage.relationshiphl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-pasCoverage.relationship.codinghl7.fhir.us.davinci-pasCoverage.statushl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-pasCoverage.subscriberhl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-pasCoverage.typehl7.fhir.us.carin-bb, hl7.fhir.us.davinci-crd
MedicationRequest bases differ 10 shared · 8 unique · 20 total
hl7.fhir.us.core → MedicationRequest (10) · hl7.fhir.us.davinci-crd → MedicationRequest (18) · hl7.fhir.us.davinci-pas → us-core-medicationrequest (14)
MedicationRequest.authoredOnallMedicationRequest.dosageInstructionallMedicationRequest.dosageInstruction.textallMedicationRequest.encounterallMedicationRequest.intentallMedicationRequest.medication[x]allMedicationRequest.reported[x]allMedicationRequest.requesterallMedicationRequest.statusallMedicationRequest.subjectallMedicationRequest.dispenseRequesthl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-pasMedicationRequest.dispenseRequest.quantityhl7.fhir.us.davinci-pasMedicationRequest.dosageInstruction.timinghl7.fhir.us.davinci-pasMedicationRequest.extensionhl7.fhir.us.davinci-crd, hl7.fhir.us.davinci-pasMedicationRequest.identifierhl7.fhir.us.davinci-crdMedicationRequest.performerhl7.fhir.us.davinci-crdMedicationRequest.priorPrescriptionhl7.fhir.us.davinci-crdMedicationRequest.reasonCodehl7.fhir.us.davinci-crdMedicationRequest.reasonReferencehl7.fhir.us.davinci-crdMedicationRequest.substitutionhl7.fhir.us.davinci-crd
Cross-cluster foundation pins (the version-axis fault line)
hl7.fhir.us.core DIVERGENT this set pins 3.1.1
hl7.fhir.us.carin-bb→7.0.0 · hl7.fhir.us.davinci-cdex→7.0.0 · hl7.fhir.us.davinci-crd→3.1.1 · hl7.fhir.us.davinci-dtr→3.1.1 · hl7.fhir.us.davinci-hrex→3.1.1 · hl7.fhir.us.davinci-pas→3.1.1 · hl7.fhir.us.davinci-pdex→7.0.0
hl7.fhir.us.davinci-hrex DIVERGENT this set pins 1.0.0
hl7.fhir.us.davinci-cdex→1.1.0 · hl7.fhir.us.davinci-crd→1.0.0 · hl7.fhir.us.davinci-dtr→1.0.0 · hl7.fhir.us.davinci-pdex→1.1.0
Handoff thread (CRD → DTR → PAS)
- CRD → DTR
ext-coverage-informationfoundBreak risk: The Coverage Information extension (coverage-assertion-id + doc requirements) and the CRD Questionnaire Task are what DTR launches from. If the payer doesn't populate doc-needed / assertion id, DTR has nothing to launch. - DTR → PAS
dtr-questionnaireresponsefoundBreak risk: PAS carries the DTR QuestionnaireResponse as supporting info; a QR that doesn't bind to the order/coverage can't be attached to the Claim. - PAS → payer
profile-pas-request-bundlefoundBreak risk: The PAS Request Bundle → Claim/$submit → X12 278 translation at the intermediary is where FHIR fidelity is lost.