Configuration, Element Type Registry and Jurisdiction Profiles

C0832What happens if someone submits a content type that the system does not recognise?

The configuration, element type registry and jurisdiction profiles part of the specification (REQ-0101) says the system must accept only content element types that exist in the signed Element Type Registry and must reject and audit any other type. The pilot covers part of this. The rest is designed, not built. Pilot detail: Signed, versioned manifest; push needs two vendor operators; policy changes need dual control. Element Type Registry beyond capabilities not built. Acceptance check: submitting an unregistered type via UI, HL7, FHIR or import returns a coded error, stores nothing, and writes a DENY audit record.

C0833What does the element type registry record about each type of clinical content?

How would it be tested? The specification says a registry release missing any attribute fails the build gate; a report lists all types with complete attributes. That is the check for REQ-0102: the Element Type Registry must store, per type, the attributes in file 01: shape, required fields, validation, class, retention, ledger code, role-tier permissions and audit events. Not yet. It is designed in the specification and not built in the pilot.

C0834Who signs each release of the element type registry, and how is it checked before use?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0103 (a top-priority requirement, all three tiers) says Registry releases must be signed by AuroraMed compliance, verified by the on-site server before activation, and their hash must be anchored to the ledger. Check: unsigned or tampered release is refused; an anchor transaction exists for each activated release.

C0835Can administrators add new members of an artifact family without waiting for a software release?

Family members (artifact families in file 01 section 6) must be creatable by authorized administrators without a software release. That is REQ-0104, a high-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: creating a family member with weaker class than its family is rejected; a valid member appears in search and audit within one minute.

C0836How many jurisdiction profiles does one deployment load, and who has to sign it?

No. The specification describes it, but the pilot does not include it. REQ-0105 says each deployment must load exactly one active Jurisdiction Profile per country context, signed by AuroraMed and countersigned by the customer's privacy officer/DPO. Its acceptance check: deployment refuses to start clinical services without a valid profile; the profile hash is on the ledger.

C0837What can a jurisdiction profile configure, such as retention, residency and breach timers?

REQ-0106 is a top-priority requirement for all three tiers: Jurisdiction Profiles must configure at least: language set, legal bases allowed, consent formats, data residency, retention periods, breach-notification timers, subject-rights SLA, DPO requirement, workforce analytics switch, and crypto-erasure acceptance. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says each parameter is present in the profile schema; missing parameters block activation; parameters with unknown legal value are shown as (still an open decision). Parts of it are explicitly marked as open in the specification.

C0838Does AuroraMed ship profile templates for US (HIPAA baseline), BR (LGPD), CO, CL, MX, PE and AR, each with values marked [verify] until counsel confirms?

The configuration, element type registry and jurisdiction profiles part of the specification (REQ-0107) says the system must ship profile templates for US (HIPAA baseline), BR (LGPD), CO, CL, MX, PE and AR, each with values marked (to be verified) until counsel confirms. Designed, not built: there is no code for this in the pilot. Acceptance check: templates load; every value derived from law carries a verification state (verified / verify / open) visible in the admin UI.

C0839Can a clinic switch between the base, local, strict and sovereign privacy tiers?

How would it be tested? The specification says switching to T-STRICT enables HYOK, per-access consent and enhanced audit only after the change-control quorum; a downgrade is blocked below legal minimums. That is the check for REQ-0108: the system must support the T-BASE, T-LOCAL, T-STRICT and T-SOVEREIGN privacy tiers as profile-controlled feature sets and must show the active tier in the administrator console. This is on the design side of the line. Nothing in v0.2.0 does it.

C0840Can one administrator change access policy, retention or alert settings alone?

The pilot covers part of this. The rest is designed, not built. Pilot detail: Signed, versioned manifest; push needs two vendor operators; policy changes need dual control. Element Type Registry beyond capabilities not built. For reference, REQ-0109 (a top-priority requirement, all three tiers) says configuration changes affecting access policy, retention, tier, alert policy or code-alert definitions must require dual control and be versioned with rollback. Check: a single administrator cannot apply such a change; rollback restores the previous version and is audited.

C0841Does AuroraMed support configuration simulation ("what-if") for access policies before activation?

The system must support configuration simulation ("what-if") for access policies before activation. That is REQ-0110, 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: a simulation report lists users/roles whose access would change; activation requires the simulation id.

C0842Does AuroraMed provide a terminology management function (import, version pin, mapping, deprecation) with a release record per code-system update?

Designed, not built: there is no code for this in the pilot. REQ-0111 says the system must provide a terminology management function (import, version pin, mapping, deprecation) with a release record per code-system update. Its acceptance check: importing a code system with bad checksum is rejected; pinned versions are shown in every coded value.

C0843Does AuroraMed maintain a Licence Register for licensed content (CPT, SNOMED CT, LOINC use terms, NANDA-I/NIC/NOC, instruments, drug knowledge bases) and block enabling content without a recorded licence?

REQ-0112 is a high-priority requirement for all three tiers: the system must maintain a Licence Register for licensed content (CPT, SNOMED CT, LOINC use terms, NANDA-I/NIC/NOC, instruments, drug knowledge bases) and block enabling content without a recorded licence. This is on the design side of the line. Nothing in v0.2.0 does it. To verify it, the specification says enabling a licensed code set without a licence record is refused.

C0844Does AuroraMed provide localization for at least en-US, es-419 and pt-BR for UI, forms, notices, alerts and patient documents, with translation review status per string?

The configuration, element type registry and jurisdiction profiles part of the specification (REQ-0113) says the system must provide localization for at least en-US, es-419 and pt-BR for UI, forms, notices, alerts and patient documents, with translation review status per string. No. The specification describes it, but the pilot does not include it. Acceptance check: switching locale changes all UI strings; strings lacking approved translation fall back to English with a visible flag.

C0845Does AuroraMed support per-facility enterprise structure (organization, facility, department, unit, room, bed) and multi-facility sphere membership?

How would it be tested? The specification says a clinic with one location and a hospital with 20 units can both be configured; access policies reference units. That is the check for REQ-0114: the system must support per-facility enterprise structure (organization, facility, department, unit, room, bed) and multi-facility sphere membership. Not built. What the pilot has is a stand-in, not the feature. Where the code stands: Unit/department are string fields on users and patients; no facility/department/room/bed master files.

C0846Does AuroraMed keep master files (locations, departments, order catalog, result catalog, charge master) under change control with effective dating?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0115 (a high-priority requirement, all three tiers) says the system must keep master files (locations, departments, order catalog, result catalog, charge master) under change control with effective dating. Check: changing an order catalog item creates a new effective-dated version; past orders keep the old version.

C0847Does AuroraMed provide build/config export and import as signed bundles for test-to-production promotion?

The system must provide build/config export and import as signed bundles for test-to-production promotion. That is REQ-0116, a medium-priority requirement for the medium and large tiers. This is on the design side of the line. Nothing in v0.2.0 does it. Test in the specification: a bundle tampered after signing fails import.

C0848Can test and training environments ever receive real patient data?

The pilot covers part of this. The rest is designed, not built. Pilot detail: All data is synthetic and demo sign-in is switched off on the live hub; no enforced block on importing real PHI into non-production. REQ-0117 says the system must support non-production environments (test, train) with synthetic data only and must block import of production PHI into them. Its acceptance check: an attempt to restore a production backup into a non-production environment is refused.