Patient identity and consent services · United States
Every record you exchange depends on two answers: is this the same person, and are we allowed to share it. We build patient matching, EMPI and MPI integrations, FHIR $match and IHE PIX and PDQ endpoints, and consent capture and enforcement for HIPAA, 42 CFR Part 2 and TEFCA.
Demographics and identifiers scored against the MPI; certain matches link, probable matches go to a data steward.
The patient's Consent and the data's sensitivity labels decide what can be shared, with whom and for what purpose.
Only permitted data leaves, and every disclosure is recorded with its purpose and recipient.
The short answer
Nirmitee builds the identity and consent layer that sits under healthcare data exchange. On identity we integrate enterprise master patient indexes, build probabilistic and deterministic matching, expose FHIR Patient $match and IHE PIX, PDQ, PIXm and PDQm, and run the merge, unmerge and data-steward workflows that keep one person as one record. On consent we capture and store FHIR Consent resources, label sensitive data such as substance use disorder records under 42 CFR Part 2, enforce policy at the API and interface layer, and verify identity for TEFCA Individual Access Services. You get fewer duplicate and overlaid records and a defensible answer to who saw what, and why.
Identity and consent standards
These are the standards and rules that decide how identity and consent work across systems.
| Standard or rule | What it is | Where it applies | What we design for |
|---|---|---|---|
| FHIR Patient $match | A FHIR R4 operation that takes a Patient resource and returns scored candidates with a match grade | EHR and payer FHIR APIs, HIEs and matching services | Input weighting from the HL7 Interoperable Digital Identity and Patient Matching guide, onlyCertainMatches, and certain, probable and possible grades |
| IHE PIX, PIXv3 and PIXm | Cross-referencing a patient's identifiers across assigning authorities (ITI-8, ITI-9, ITI-44, ITI-45, ITI-83) | Hospitals, HIEs and national networks | Identifier feeds from ADT, domain-aware queries and merge propagation |
| IHE PDQ, PDQv3 and PDQm | Demographic queries that return candidate patients (ITI-21, ITI-47, ITI-78) | Registration, HIE lookups and app onboarding | Search on name, birth date, sex and address with paging and minimum-necessary results |
| HL7 v2 ADT identity events | A04 registration, A08 update, A31 person update, A40 merge, A37 unlink | Every hospital feed | Merges that re-point every downstream record to the surviving identifier, and unmerge when a merge was wrong |
| FHIR Consent | A FHIR R4 resource recording who agreed to what, for which purpose, actors, data and period, with permit and deny provisions | Patient apps, HIEs, research and payer exchange | Machine-readable provisions an API can enforce, not a scanned form alone |
| 42 CFR Part 2 | Federal confidentiality rule for substance use disorder treatment records; the 2024 final rule allows a single consent for treatment, payment and health care operations, with compliance required from 16 February 2026 | SUD programs and anyone receiving their records | Security labels on Part 2 data, consent checks before disclosure, redisclosure notices and accounting of disclosures |
| TEFCA Individual Access Services | The TEFCA exchange purpose that lets individuals retrieve their own records through an IAS provider | Consumer apps and IAS providers connecting through a QHIN | Identity verification to NIST 800-63 IAL2 before records are released, as the IAS rules require |
| HIPAA Privacy Rule | Uses and disclosures, minimum necessary, right of access and accounting | Every covered entity and business associate | Purpose-of-use on every request and an audit trail that answers an access request |
State law often goes further than HIPAA for minors, reproductive health, HIV and behavioral health records. We model state rules as policy so they can change without new code.
What we build
Pick the workstreams your exchange needs. Each ships with a specification, tests and an owner.
Connections between your systems and an enterprise master patient index, including identifier feeds, search, link and merge events, and reconciliation of historic duplicates.
EMPI · ADT A04 A08 A31 A40 · PIX feed
Patient matching and MPI beyond demographics →Deterministic and probabilistic matching with tuned weights and thresholds, exposed as FHIR Patient $match, with certain, probable and possible grades and a data-steward queue.
FHIR $match · match-grade · Fellegi-Sunter · IDI Patient
FHIR integration services →PIX and PDQ in HL7 v2, v3 and FHIR (PIXm, PDQm) for HIE and network participation, including XCPD patient discovery where a network requires it.
ITI-8 · ITI-9 · ITI-21 · ITI-78 · ITI-83 · ITI-55
HIE integration services →Consent flows in your app or intake process that produce FHIR Consent resources with purpose, actors, data scope and period, plus revocation and expiry handling.
FHIR Consent · Provenance · e-signature
The FHIR Consent resource and TEFCA →Policy checks at the API gateway and interface engine, security labels on sensitive data such as 42 CFR Part 2 records, and redisclosure notices on outbound documents.
Security labels · purpose of use · Part 2 · AuditEvent
TEFCA integration services →Identity proofing at IAL2 with a credential service provider, linked to the patient's records before an IAS request is sent through a QHIN.
TEFCA IAS · NIST 800-63 IAL2 · OpenID Connect
TEFCA explained for developers and CTOs →Buyer decisions
The matching approach is a buying decision. We integrate all of these and build where it makes sense.
| Option | Best fit | Strengths | What to plan for |
|---|---|---|---|
| Commercial EMPI | Health systems, HIEs and payers with many source systems | Mature matching, data-steward tools and support | License cost, integration with every source and tuning for your population |
| Referential matching service | Organizations with thin or outdated demographics | Matches against a reference database of identities, which helps with address and name changes | Per-transaction fees and data sharing terms |
| The EHR's own MPI | Organizations where one EHR is the system of record | Already in place; matches stay consistent with the chart | Limited reach across systems outside that EHR |
| Custom matching service | Health tech products with a defined population and data model | Full control over weights, thresholds and review flow | You own tuning, testing against labeled pairs and ongoing stewardship |
| Network patient discovery | Organizations joining TEFCA, Carequality or an HIE | Finds records held elsewhere | Each network's matching rules and response times |
Every approach needs a data steward and a measured false-match rate. An overlaid record is a patient safety event, not a data quality issue.
Integration boundaries
Identity and consent decisions carry legal weight. We write down who decides and who builds.
Decide consent policy, purposes of use, state law interpretation and 42 CFR Part 2 obligations. We turn the signed-off policy into rules the system enforces.
Owns data stewardship: reviewing probable matches, approving merges and resolving overlays. We build the queues and tools they work in.
Own their matching engines and network rules. We integrate to their interfaces and tune within the settings they expose.
Identifier feeds, matching services, $match, PIX and PDQ endpoints, consent capture, policy enforcement points and audit logging. Defects in this layer are ours to fix.
Identity data is among the most sensitive PHI you hold. We sign a BAA, encrypt in transit and at rest, and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything below lands in your repository and your runbook.
Identifiers and assigning authorities, match inputs and thresholds, consent model, policies and enforcement points.
Matching, $match, PIX and PDQ, consent and enforcement code or engine configuration.
Precision and recall measured on labeled record pairs from your own data, with the threshold recommendation.
Rules for HIPAA, 42 CFR Part 2 and applicable state law, versioned and reviewed by your compliance team.
Twins, name changes, merges, unmerges, revoked consent, expired consent and Part 2 redisclosure cases.
Review queues, merge and unmerge procedures, audit reports and an escalation path for suspected overlays.
Delivery phases
A matching service or EMPI integration with consent enforcement typically takes 10 to 16 weeks. Policy sign-off and access to representative data set most of that date.
Weeks 1 to 3
Identifier inventory, consent policy workshop with compliance, specification drafted
Weeks 2 to 7
Matching built and measured on labeled pairs, thresholds agreed with HIM
Weeks 5 to 12
Consent capture, labels and enforcement points built and tested against policy cases
Weeks 10 to 16
Cutover, historic duplicate cleanup plan, steward queues live and runbook handed over
Cost drivers
You get a fixed scope and price after one scoping call. These are the factors that move it.
Each system brings its own identifiers, data quality and feed.
Cleaning up years of duplicates is a separate workstream from matching new records.
Integrating a commercial EMPI differs from building and tuning a custom matcher.
HIPAA-only exchange is simpler than Part 2, research and state-specific rules.
PIX, PDQ, XCPD and TEFCA IAS each add their own testing with the network.
Steward tooling, monitoring and on-call are priced per environment.
Proof
Client names are withheld. The code and write-ups linked here are public.
Our headless EHR includes patient demographics, matching and merging, SMART on FHIR authorization with v1 and v2 scopes and break-glass audit. It passed all 47 ONC (g)(10) SMART App Launch tests in Inferno on 11 June 2026.
View the headless EHR on GitHub →For a regional cancer network we built a case exchange in which each hospital keeps its records at home and shares only what the tumor board needs, under each hospital's own consent and data protection rules.
We built patient registration against a national health ID system, with identity verification, consent and the resulting records mapped to FHIR.
Our platform runs identity, HL7 v2, FHIR and X12 connectors behind one API, with audit logging and monitoring built in.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
An enterprise master patient index links the records one person has across your systems under a single enterprise identifier. You need one when several systems register patients independently, such as a health system with multiple EHRs, an HIE or a payer with many data sources. A single-EHR organization can often rely on that EHR's MPI.
Matching compares demographics and identifiers such as name, birth date, sex, address, phone, email and MRNs. Deterministic rules link on exact identifier agreement; probabilistic matching weighs each field's agreement and rarity and scores the pair. Scores above a threshold link automatically, and a middle band goes to a data steward for review.
$match is a FHIR R4 operation on Patient that accepts a Patient resource with the demographics you have and returns candidate records with a score and a match grade of certain, probable, possible or certainly not. The HL7 Interoperable Digital Identity and Patient Matching guide adds guidance on input quality and weighting.
PIX (Patient Identifier Cross-referencing) links a patient's identifiers from different assigning authorities, and PDQ (Patient Demographics Query) returns patients that match a demographic search. Both exist in HL7 v2, v3 and FHIR forms (PIXm and PDQm) and are used by HIEs and national networks.
We measure matching on labeled record pairs from your data, set thresholds with your HIM team, send uncertain pairs to a steward queue, and treat merges as events that re-point every downstream record. Overlays, where two people share one record, get an alert and an unmerge procedure.
The FHIR R4 Consent resource records the patient, the policy, the purpose of use, the actors, the data covered and the period, with permit and deny provisions. Stored this way, an API or interface engine can enforce the consent automatically instead of relying on a scanned form.
The February 2024 final rule aligned Part 2 more closely with HIPAA. A patient can give a single consent for all future uses for treatment, payment and health care operations, recipients that are covered entities may redisclose under HIPAA, and breach notification now applies. Compliance was required from 16 February 2026.
We tag sensitive data with security labels at the point it enters the system, check the patient's consent and the requester's purpose before disclosure, attach the required redisclosure notice and record every disclosure. Policy lives in versioned rules so your compliance team can review it.
Individual Access Services let people retrieve their own records through an IAS provider connected to a QHIN. Before records are released, the IAS rules require the individual's identity to be verified to NIST 800-63 IAL2 and matched to their records. We build that proofing and linking flow with a credential service provider.
A matching service or EMPI integration with consent enforcement typically takes 10 to 16 weeks. Policy sign-off, access to representative data for match evaluation and any network testing set most of that timeline.
Cost depends on the number of source systems, historic duplicate cleanup, the matching approach, consent complexity, network participation and the support level. We give a fixed scope and price after one scoping call.
Yes. We sign Business Associate Agreements, encrypt identity data in transit and at rest, log every access and work inside our ISO 27001:2022 certified management system.
Next step
Tell us your systems, networks and the consent rules you work under. An engineer replies with the matching approach, the enforcement points and a fixed scope.
Start with your workflow
Share your source systems, networks and consent requirements, plus your target date. Use de-identified examples only. Read by an engineer, answered within one business day.
