Patient identity and master patient index

C0548Does AuroraMed create a patient record with a unique internal identifier, never derived from a national identifier?

It is one of the few requirements the pilot meets at MVP scope; nothing has touched real data. Pilot detail: Internal UUID + per-clinic MRN (Luhn); SSN masked by default, reveal needs a purpose and is audited. REQ-0201 says the system must create a patient record with a unique internal identifier, never derived from a national identifier. Its acceptance check: two patients with the same CPF/SSN receive different internal ids; no key or ledger field equals a national id.

C0549Does AuroraMed capture multiple identifier types per patient with issuer, period and status?

REQ-0202 is a top-priority requirement for all three tiers: the system must capture multiple identifier types per patient with issuer, period and status. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says adding an identifier with an unknown issuer type is rejected.

C0550Are national ID numbers such as CPF, CNS, RUT, CURP, DNI, NPI and MBI checked and stored encrypted?

The patient identity and master patient index part of the specification (REQ-0203) says the system must validate national identifiers with the checksum of their type (CPF, CNS, RUT, CURP, DNI, NPI, MBI format) and must store them encrypted with a blind index. Designed, not built: there is no code for this in the pilot. Acceptance check: invalid CPF check digit is rejected; a database dump shows ciphertext only; equality search works via the blind index.

C0551How does AuroraMed find duplicate patients, and can the matching weights be tuned?

How would it be tested? The specification says a test set of 1,000 seeded duplicates reports recall and precision; algorithm version is recorded with every decision. That is the check for REQ-0204: the system must support deterministic and probabilistic patient matching with configurable weights and phonetic/fuzzy name matching, and must present candidates with scores. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Deterministic + weighted probabilistic (Soundex/Jaro-Winkler style) matching with live duplicate warning; weights not yet per-tenant configurable.

C0552Does AuroraMed support two-identifier verification prompts at registration, order entry, specimen collection, medication administration and transfusion?

No. The specification describes it, but the pilot does not include it. For reference, REQ-0205 (a top-priority requirement, all three tiers) says the system must support two-identifier verification prompts at registration, order entry, specimen collection, medication administration and transfusion. Check: barcode workflow refuses to proceed with one identifier only when the site policy requires two.

C0553Does AuroraMed support unknown-patient (Doe) registration with temporary identity, later merge to a real identity, and full reversal (unmerge)?

The system must support unknown-patient (Doe) registration with temporary identity, later merge to a real identity, and full reversal (unmerge). That is REQ-0206, a top-priority requirement for all three tiers. The pilot covers part of this. The rest is designed, not built. Where the code stands: Unknown-patient registration and two-person MERGE (virtual, unmerge supported); no ADT A40/A37 or FHIR Linkage emission. Test in the specification: merge then unmerge restores both records byte-identical in content; audit shows both.

C0554Who has to approve a patient merge or unmerge, and does it notify other systems?

The pilot covers part of this. The rest is designed, not built. In the pilot: Unknown-patient registration and two-person MERGE (virtual, unmerge supported); no ADT A40/A37 or FHIR Linkage emission. REQ-0207 says merge and unmerge must require two-person approval and must emit ADT A40/A37 (or FHIR Linkage/Patient replaced-by) to interfaces. Its acceptance check: single-person merge attempt is blocked; downstream systems receive the event.

C0555Does AuroraMed support name history: legal, chosen, previous, alias, with pronouns and display rules?

REQ-0208 is a top-priority requirement for all three tiers: the system must support name history: legal, chosen, previous, alias, with pronouns and display rules. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Preferred name/name fields, data-quality tab, visits (AMB/IMP/EMER), edit history stores field names only with values encrypted; not the full spec model. To verify it, the specification says chosen name appears on banner and wristband per site policy while legal name is retained for billing.

C0556Does AuroraMed record sex and gender data as separate fields (administrative sex, sex for clinical use, gender identity, sexual orientation) with a declined option?

The patient identity and master patient index part of the specification (REQ-0209) says the system must record sex and gender data as separate fields (administrative sex, sex for clinical use, gender identity, sexual orientation) with a declined option. No. The specification describes it, but the pilot does not include it. Acceptance check: declined is stored distinctly from unknown; each field has its own privacy setting.

C0557Does AuroraMed record race, ethnicity and language with multi-select, declined option and interpreter need?

How would it be tested? The specification says interpreter-needed flag surfaces on scheduling and rooming. That is the check for REQ-0210: the system must record race, ethnicity and language with multi-select, declined option and interpreter need. Not yet. It is designed in the specification and not built in the pilot.

C0558Does AuroraMed link mothers and newborns and multiple-birth siblings with permanent links that only HIM can change?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0211 (a top-priority requirement, all three tiers) says the system must link mothers and newborns and multiple-birth siblings with permanent links that only HIM can change. Check: a user without HIM tier cannot remove the link.

C0559Does AuroraMed support related persons: emergency contacts, guarantors, guardians, proxies with scope, period and authority document?

The system must support related persons: emergency contacts, guarantors, guardians, proxies with scope, period and authority document. That is REQ-0212, a top-priority requirement for all three tiers. This is on the design side of the line. Nothing in v0.2.0 does it. Test in the specification: expired proxy loses access automatically; proxy scope limits visible categories.

C0560Does AuroraMed support VIP/restricted/confidential patient flags with hidden-flag option and access requirement of relationship or break-glass?

The pilot covers part of this. The rest is designed, not built. Pilot detail: VIP/restricted flags (hidden from non-care-team lists) with break-glass access; hidden-flag option not separate. REQ-0213 says the system must support VIP/restricted/confidential patient flags with hidden-flag option and access requirement of relationship or break-glass. Its acceptance check: access without relationship prompts break-glass and generates a review item.

C0561Does AuroraMed support registration alerts and flags (infection, behavioral, safety) with expiry and review dates?

REQ-0214 is a high-priority requirement for all three tiers: the system must support registration alerts and flags (infection, behavioral, safety) with expiry and review dates. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says flags past expiry appear on a review worklist.

C0562Does AuroraMed capture patient photos with consent, strip metadata, and use them only for identity verification per policy?

The patient identity and master patient index part of the specification (REQ-0215) says the system must capture patient photos with consent, strip metadata, and use them only for identity verification per policy. Designed, not built: there is no code for this in the pilot. Acceptance check: photo capture requires consent flag; EXIF removed.

C0563Does AuroraMed optionally support biometric identification (palm-vein, fingerprint, iris) as an opt-in per jurisdiction profile, storing templates only?

How would it be tested? The specification says disabled by default; enabling requires DPO sign-off; raw images are not retained. That is the check for REQ-0216: the system must optionally support biometric identification (palm-vein, fingerprint, iris) as an opt-in per jurisdiction profile, storing templates only. This is on the design side of the line. Nothing in v0.2.0 does it.

C0564Does AuroraMed provide a duplicate-record worklist and overlay/overlap resolution tools for HIM?

No. The specification describes it, but the pilot does not include it. For reference, REQ-0217 (a high-priority requirement, all three tiers) says the system must provide a duplicate-record worklist and overlay/overlap resolution tools for HIM. Check: worklist filters by score and age; each disposition is audited.

C0565Does AuroraMed support IHE PIX/PDQ/PIXm/PDQm and FHIR Patient $match for identity queries subject to consent and policy?

The system must support IHE PIX/PDQ/PIXm/PDQm and FHIR Patient $match for identity queries subject to consent and policy. That is REQ-0218, a high-priority requirement for the medium and large tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: conformance test passes against a reference implementation.

C0566Does AuroraMed create and maintain cross-sphere patient linkage only through consented BridgeLinkage records?

Designed, not built: there is no code for this in the pilot. REQ-0219 says the system must create and maintain cross-sphere patient linkage only through consented BridgeLinkage records. Its acceptance check: no link exists without a CONS reference; erasing r_patient breaks the link.

C0567Does AuroraMed provide demographic data quality dashboards (missing DOB, invalid identifiers, address failures)?

REQ-0220 is a medium-priority requirement for the medium and large tiers: the system must provide demographic data quality dashboards (missing DOB, invalid identifiers, address failures). The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Preferred name/name fields, data-quality tab, visits (AMB/IMP/EMER), edit history stores field names only with values encrypted; not the full spec model. To verify it, the specification says dashboard counts match a seeded test dataset.

C0568Does AuroraMed standardize addresses with country-specific formats and code tables (USPS, CEP/IBGE, DANE, INEGI, UBIGEO)?

The patient identity and master patient index part of the specification (REQ-0221) says the system must standardize addresses with country-specific formats and code tables (USPS, CEP/IBGE, DANE, INEGI, UBIGEO). No. The specification describes it, but the pilot does not include it. Acceptance check: address entered in each supported country validates or offers correction.

C0569Does AuroraMed scan and OCR insurance and identification cards into structured fields with human confirmation?

How would it be tested? The specification says oCR output is never saved without user confirmation. That is the check for REQ-0222: the system must scan and OCR insurance and identification cards into structured fields with human confirmation. Not yet. It is designed in the specification and not built in the pilot.

C0570Does AuroraMed support patient-side identity proofing at IAL2-style assurance for wallet enrollment (in person or remote)?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0223 (a high-priority requirement, all three tiers) says the system must support patient-side identity proofing at IAL2-style assurance for wallet enrollment (in person or remote). Check: in-person enrollment requires government ID check recorded by a witness wallet.

C0571Does AuroraMed mask national identifiers by default and require purpose for unmasking, auditing each unmasking?

The system must mask national identifiers by default and require purpose for unmasking, auditing each unmasking. That is REQ-0224, a top-priority requirement for all three tiers. It is one of the few requirements the pilot meets at MVP scope; nothing has touched real data. What v0.2.0 does today: Internal UUID + per-clinic MRN (Luhn); SSN masked by default, reveal needs a purpose and is audited. Test in the specification: unmask event appears in audit with purpose.

C0572Does AuroraMed record deceased status and propagate suppression to scheduling and outreach?

No. The specification describes it, but the pilot does not include it. REQ-0225 says the system must record deceased status and propagate suppression to scheduling and outreach. Its acceptance check: deceased patient receives no reminders; reversal requires HIM.