Health systems with several EHRs
Mergers leave the same patient in several systems under different record numbers, and clinicians cannot see the whole history.
Healthcare / Patient Identity and Consent
Patient identity and consent management software
Duplicate records split a patient's history, and consent kept in scanned PDFs cannot stop a data feed. Agnotic Technologies builds patient identity matching and consent services that link the right records and check what each patient has agreed to before any data leaves your systems.
EMPI
Matching across systems
IAL
Identity proofing levels
FHIR Consent
Enforced at release
Trusted by global innovators
Industry Overview
What is patient identity and consent management?
Patient identity and consent management is the software that works out who a patient is across systems and what that patient has agreed to share. Agnotic Technologies builds enterprise master patient index (EMPI) matching, duplicate review queues, identity proofing for patient apps, and consent capture that is enforced at every API and data feed.
Who it is for
Who needs identity and consent software?
The organizations that most often ask us for this work, and the problem each one brings.
HIEs and data networks
Records from many sources must be linked to one person before they can be shared, and each source brings its own consent rules.
Digital health apps
Patients sign up remotely, so the app must confirm who they are before it connects them to their records.
Substance use disorder treatment programs
Records covered by 42 CFR Part 2 need their own consent and must stay apart from general records unless the patient agrees.
Industry Challenges
Where do patient matching and consent fail?
The failure points we look for first when we review an identity or consent setup.
Duplicates: one patient has several records, so allergies, results and medications are split across them.
Overlays: two different patients are merged into one record, which is harder to spot and more dangerous than a duplicate.
No unmerge path: a wrong merge cannot be reversed cleanly, because the history of the merge was never stored.
Consent as a document: consent lives in a scanned PDF that no system can read, so feeds and APIs never check it.
One-size identity proofing: an app asks for too little to protect records, or so much that genuine patients give up.
Mixed sensitive records: Part 2 or other restricted data sits in the same store as general records with no labels to filter it.
Decision table
Which matching approach fits which job?
Most EMPIs combine several of these approaches. The right mix depends on the quality of your data and the cost of a wrong match.
| Approach | How it decides | Good for | Watch out for |
|---|---|---|---|
| Deterministic rules | Exact or near-exact agreement on chosen fields, such as a medical record number plus date of birth | Clean data with reliable identifiers | Missed matches when names or numbers are mistyped |
| Probabilistic scoring | Weighted scores across name, birth date, address, phone and sex, tuned to your data | Mixed data from several source systems | Thresholds that need tuning and regular review |
| Referential matching | Compares records against an external reference data set of identities | Patients who move or change names often | Licensing, data sharing terms and cost |
| Machine learning ranking | A trained model ranks candidate pairs found by the rules above | Large volumes with past review decisions to learn from | Explainability and drift as data changes |
| Human review queue | A trained registrar or data steward decides uncertain pairs | Scores in the grey zone between auto-link and no-match | Queue backlogs and inconsistent decisions |
Our Approach
How do we approach identity and consent work?
Three decisions on the scoping call shape the build.
Set thresholds by the cost of error
We agree with your clinical and HIM leads where a match is linked automatically, where it goes to review, and where a new identity is created.
Make consent computable
Consent is stored as structured data, such as a FHIR Consent resource, so every feed and API can check it before release.
Match proofing to risk
We choose an identity assurance level for each patient app flow, guided by NIST SP 800-63A and your own risk assessment.
Capabilities
What do we build for patient identity and consent?
How to build patient identity and consent management that clinicians and registrars trust: services and tools built for your systems and your rules.
EMPI and matching service
Standardizes names, addresses and phone numbers, finds candidate records and scores them, exposed through a FHIR Patient $match API.
Duplicate and overlay review
A work queue for data stewards with side-by-side record views, decision reasons and second review for high-risk merges.
Merge and unmerge with history
Every link and merge is stored with who made it and why, so a wrong merge can be reversed and downstream systems told.
Identity proofing for patient apps
Sign-up flows that collect and check identity evidence at the assurance level you choose, before records are linked to an account.
Consent capture
Electronic consent forms in portals, apps and at registration, stored as structured records with versions, expiry and revocation.
Consent enforcement service
A policy check called by APIs, feeds and exports before release, which filters or blocks data the patient has not agreed to share.
Sensitive data labelling
Labels on Part 2 and other restricted records so they can be held back, released only with the right consent, or shared under the rules that apply.
Audit and reporting
Logs of every match decision, consent change and release check, with reports for privacy and HIM teams.
How It Works
How does a record move through matching and consent checks?
Each stage has its own failure mode, so we design, log and monitor each one separately.
Intake
A registration, an HL7 v2 ADT message, an app sign-up or an incoming record from a partner arrives with demographic data.
01
1
Standardize
Names, addresses, phone numbers and dates are cleaned into one format, and obvious placeholder values are flagged.
02
2
Match and score
Candidate records are found and scored with the agreed rules and weights, and each score is stored with the fields that drove it.
03
3
Decide
High scores link automatically, grey-zone scores go to the review queue, and low scores create a new identity.
04
4
Check consent at release
Before any data leaves through an API, feed or export, the consent service checks the patient's current choices and the data's sensitivity labels.
05
5
Audit
Every decision and release check is logged, and merge or consent changes are pushed to downstream systems.
06
6
Engineering Stack
Standards and technologies for identity and consent
Chosen to fit your EHRs, your network partners and your identity provider.
Identity standards
FHIR R4 Patient and $matchHL7 v2 ADT, including merge eventsOpenID ConnectSMART on FHIR
Consent standards
FHIR R4 ConsentSecurity labels for sensitive dataC-CDA privacy markingsPolicy rules engines
Matching
Probabilistic matching librariesSearch indexes for candidate lookupAddress and name standardizationReview queue tooling
Security
NIST SP 800-63A identity assurance levelsRole-based accessEncryption and key managementTamper-evident audit logs
Measured Impact
What should an identity and consent program measure?
Measures we build dashboards around and review with your HIM and privacy teams.
Duplicates
Duplicate record trend
New and resolved duplicates over time, by source system.
Queue age
Review backlog
How long uncertain matches wait for a data steward's decision.
Consent coverage
Structured consent on file
Patients whose consent is stored as data rather than as a scanned document.
Blocked releases
Consent checks that stopped data
Release checks that filtered or blocked data, reviewed for errors.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Compliant Women’s Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Where do teams start?
Common first releases, each scoped to one source system or one consent type.
01
Duplicate cleanup after a merger
Matching two EHR populations and working the review queue.
02
Matching API for a partner network
A FHIR Patient $match service for HIE or network queries.
03
Patient app sign-up
Identity proofing and record linking for a new patient app.
04
Electronic consent at registration
Replacing paper consent with structured, versioned records.
05
Part 2 consent and labelling
Separate consent and data labels for substance use disorder records.
06
Consent check on data exports
Adding a release check to research and analytics extracts.
Integrations
Which systems do identity and consent services connect to?
The systems that send demographic data in and the systems that must check identity and consent before data goes out.
Clinical record
EHRs (Epic, Oracle Health (Cerner), others)
Intake
Registration and scheduling
Exchange
HIEs and TEFCA participants
Sign-up and consent
Patient portals and apps
Login
Identity providers
Secondary use
Data warehouse and research extracts
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
Fast Healthcare Interoperability Resources
Enabling standardized health data exchange through standards-based API mappings.
Health Level Seven International
Supporting enterprise-grade interoperability for clinical messaging and record workflows.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we reduce development cycles and get your product to market 40% faster.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does an engagement work?
We start with one source system or one consent type. Timing depends on scope; we agree a fixed first release on the scoping call.
01
Scoping call
We review your systems, data quality, consent forms and the first problem to solve.
02
Data profiling
We measure field completeness and duplicate patterns on a de-identified sample or inside your environment.
03
Rules and policy design
Match thresholds, review rules and consent policies are agreed with HIM, privacy and clinical leads.
04
Fixed-scope first release
Matching or consent working for one source or one consent type, with audit and monitoring.
05
Support and tuning
Threshold tuning, new sources and policy changes under agreed change control.
Facts and sources
Rules and standards behind identity and consent
Short facts we design around, each linked to its primary source.
In HL7 FHIR R4, clients ask a master patient index to match a patient through the Patient $match operation, which returns candidate records with a score from 0 to 1 and a match grade.
Source: HL7 FHIR R4, Patient $match operationThe HL7 FHIR R4 Consent resource records a healthcare consumer's choices that permit or deny identified recipients to perform actions within a policy context, for specific purposes and periods of time.
Source: HL7 FHIR R4, ConsentNIST SP 800-63A-4 sets technical requirements for identity proofing at three identity assurance levels, IAL1, IAL2 and IAL3, each adding evidence and verification rigor to the one below.
Source: NIST SP 800-63A-4, Identity Proofing and EnrollmentA written consent under 42 CFR Part 2 may be paper or electronic and must include the patient's name, who may disclose, a specific description of the information, the recipients and a description of each purpose.
Source: 42 CFR 2.31(a) (eCFR)A covered entity must agree to a patient's request not to disclose information to a health plan for payment or operations when the patient has paid in full out of pocket for that item or service, unless the law requires the disclosure.
Source: 45 CFR 164.522(a)(1)(vi) (eCFR)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related pages
Related exchange and patient access services
This page covers identity and consent. These pages cover the exchange and access work that depends on it.
Health information exchange software
HIE platforms where records from many sources are linked and shared.
TEFCA integration services
Connecting to nationwide exchange, where matching and consent rules also apply.
Patient portal development
Portals where patients sign up, prove who they are and manage consent.
SMART on FHIR app development
Apps that launch with the patient's identity and scopes from the EHR.
HIPAA requirements for software teams
The privacy and security safeguards behind every consent decision.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
The number of source systems, the quality of their demographic data, the size of the duplicate backlog, the consent types to support and how many feeds and APIs need a release check. We explain these drivers on the scoping call instead of quoting a fixed price.
It depends on scope. We agree a fixed first release, usually matching for one source system or structured consent for one consent type, on the scoping call.
Often both. A commercial EMPI can provide the matching engine, while custom work covers review tools, consent enforcement and the interfaces to your systems. We compare your data and volumes against the options before recommending either.
Part 2 records get their own consent records, with the elements 42 CFR 2.31 requires, and data labels that keep them out of general releases unless the patient's consent allows it. Your privacy counsel sets the policy; we build it into the release check.
It depends on what the app exposes. NIST SP 800-63A defines three identity assurance levels; we choose one per flow with your security team, for example a stronger level before an account can see records.
The software has to support Privacy Rule duties such as authorizations and agreed restrictions, plus Security Rule safeguards such as access control and audit logs. We build HIPAA-ready software, and Agnotic signs a business associate agreement before PHI is shared.
Yes. Consent records are versioned, so a change or revocation takes effect at the next release check, and the old version stays in the audit trail.
Industries