AuroraMed v0.2.0 is a synthetic-data pilot. See exactly what's built →

Help center

The specification, requirement by requirement

The AuroraMed specification has 454 functional requirements in 49 modules. As of September 30, 2026, 8 are built at MVP scope in the synthetic-data pilot, 53 are partly built, 9 are placeholders and 384 are not built. That is what an honest coverage table looks like.

Reading this table

Counts come from the developer's own gap analysis of the pilot against the specification. They are not a measure of percent complete, and requirements differ enormously in size. Wave 2 items are labelled Coming until verified.

Configuration, Element Type Registry and Jurisdiction Profiles (17)

Governs which content exists, how it is classified and how each country/state behaves.

IDRequirementPilot statusAnswer
REQ-0101The system shall accept only content element types that exist in the signed Element Type Registry and shall reject and audit any other type.Pilot Partly builtC0832
REQ-0102The Element Type Registry shall store, per type, the attributes in file 01: shape, required fields, validation, class, retention, ledger code, role-tier permissions and audit events.Designed Not builtC0833
REQ-0103Registry releases shall be signed by AuroraMed compliance, verified by the on-site server before activation, and their hash shall be anchored to the ledger.Designed Not builtC0834
REQ-0104Family members (artifact families in file 01 section 6) shall be creatable by authorized administrators without a software release.Designed Not builtC0835
REQ-0105Each deployment shall load exactly one active Jurisdiction Profile per country context, signed by AuroraMed and countersigned by the customer's privacy officer/DPO.Designed Not builtC0836
REQ-0106Jurisdiction Profiles shall 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.Designed Not builtC0837
REQ-0107The system shall ship profile templates for US (HIPAA baseline), BR (LGPD), CO, CL, MX, PE and AR, each with values marked [verify] until counsel confirms.Designed Not builtC0838
REQ-0108The system shall support the T-BASE, T-LOCAL, T-STRICT and T-SOVEREIGN privacy tiers as profile-controlled feature sets and shall show the active tier in the administrator console.Designed Not builtC0839
REQ-0109Configuration changes affecting access policy, retention, tier, alert policy or code-alert definitions shall require dual control and be versioned with rollback.Pilot Partly builtC0840
REQ-0110The system shall support configuration simulation ("what-if") for access policies before activation.Designed Not builtC0841
REQ-0111The system shall provide a terminology management function (import, version pin, mapping, deprecation) with a release record per code-system update.Designed Not builtC0842
REQ-0112The system shall 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.Designed Not builtC0843
REQ-0113The system shall 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.Designed Not builtC0844
REQ-0114The system shall support per-facility enterprise structure (organization, facility, department, unit, room, bed) and multi-facility sphere membership.Designed Placeholder onlyC0845
REQ-0115The system shall keep master files (locations, departments, order catalog, result catalog, charge master) under change control with effective dating.Designed Not builtC0846
REQ-0116The system shall provide build/config export and import as signed bundles for test-to-production promotion.Designed Not builtC0847
REQ-0117The system shall support non-production environments (test, train) with synthetic data only and shall block import of production PHI into them.Pilot Partly builtC0848

Patient identity and master patient index (25)

Registration identity, matching, merge, cross-sphere linkage.

IDRequirementPilot statusAnswer
REQ-0201The system shall create a patient record with a unique internal identifier, never derived from a national identifier.Pilot Built at MVP scopeC0548
REQ-0202The system shall capture multiple identifier types per patient with issuer, period and status.Designed Not builtC0549
REQ-0203The system shall validate national identifiers with the checksum of their type (CPF, CNS, RUT, CURP, DNI, NPI, MBI format) and shall store them encrypted with a blind index.Designed Not builtC0550
REQ-0204The system shall support deterministic and probabilistic patient matching with configurable weights and phonetic/fuzzy name matching, and shall present candidates with scores.Pilot Partly builtC0551
REQ-0205The system shall support two-identifier verification prompts at registration, order entry, specimen collection, medication administration and transfusion.Designed Not builtC0552
REQ-0206The system shall support unknown-patient (Doe) registration with temporary identity, later merge to a real identity, and full reversal (unmerge).Pilot Partly builtC0553
REQ-0207Merge and unmerge shall require two-person approval and shall emit ADT A40/A37 (or FHIR Linkage/Patient replaced-by) to interfaces.Pilot Partly builtC0554
REQ-0208The system shall support name history: legal, chosen, previous, alias, with pronouns and display rules.Pilot Partly builtC0555
REQ-0209The system shall record sex and gender data as separate fields (administrative sex, sex for clinical use, gender identity, sexual orientation) with a declined option.Designed Not builtC0556
REQ-0210The system shall record race, ethnicity and language with multi-select, declined option and interpreter need.Designed Not builtC0557
REQ-0211The system shall link mothers and newborns and multiple-birth siblings with permanent links that only HIM can change.Designed Not builtC0558
REQ-0212The system shall support related persons: emergency contacts, guarantors, guardians, proxies with scope, period and authority document.Designed Not builtC0559
REQ-0213The system shall support VIP/restricted/confidential patient flags with hidden-flag option and access requirement of relationship or break-glass.Pilot Partly builtC0560
REQ-0214The system shall support registration alerts and flags (infection, behavioral, safety) with expiry and review dates.Designed Not builtC0561
REQ-0215The system shall capture patient photos with consent, strip metadata, and use them only for identity verification per policy.Designed Not builtC0562
REQ-0216The system shall optionally support biometric identification (palm-vein, fingerprint, iris) as an opt-in per jurisdiction profile, storing templates only.Designed Not builtC0563
REQ-0217The system shall provide a duplicate-record worklist and overlay/overlap resolution tools for HIM.Designed Not builtC0564
REQ-0218The system shall support IHE PIX/PDQ/PIXm/PDQm and FHIR Patient $match for identity queries subject to consent and policy.Designed Not builtC0565
REQ-0219The system shall create and maintain cross-sphere patient linkage only through consented BridgeLinkage records.Designed Not builtC0566
REQ-0220The system shall provide demographic data quality dashboards (missing DOB, invalid identifiers, address failures).Pilot Partly builtC0567
REQ-0221The system shall standardize addresses with country-specific formats and code tables (USPS, CEP/IBGE, DANE, INEGI, UBIGEO).Designed Not builtC0568
REQ-0222The system shall scan and OCR insurance and identification cards into structured fields with human confirmation.Designed Not builtC0569
REQ-0223The system shall support patient-side identity proofing at IAL2-style assurance for wallet enrollment (in person or remote).Designed Not builtC0570
REQ-0224The system shall mask national identifiers by default and require purpose for unmasking, auditing each unmasking.Pilot Built at MVP scopeC0571
REQ-0225The system shall record deceased status and propagate suppression to scheduling and outreach.Designed Not builtC0572

Registration, ADT, bed management and patient access (22)

Front-desk, encounter, admission/transfer/discharge, bed and transport workflows.

IDRequirementPilot statusAnswer
REQ-0301The system shall register outpatient, emergency, inpatient, observation, home-visit and virtual encounters with class, type, location and participants.Pilot Partly builtC0573
REQ-0302The system shall support pre-registration and digital/kiosk check-in with identity and consent capture.Designed Not builtC0574
REQ-0303The system shall support ED quick registration, mass-casualty registration and unknown-patient shortcuts.Designed Not builtC0575
REQ-0304The system shall support admission, transfer, discharge, cancel-admit, cancel-transfer and cancel-discharge with correct state transitions.Designed Not builtC0576
REQ-0305The system shall emit and consume HL7 v2 ADT events and FHIR Encounter changes.Designed Not builtC0577
REQ-0306The system shall provide a bed board and census with bed status (available, occupied, cleaning, blocked) and isolation/acuity matching.Designed Not builtC0578
REQ-0307The system shall provide a transfer center for inbound/outbound transfers including EMTALA documentation and acceptance recording.Designed Not builtC0579
REQ-0308The system shall track observation status with Two-Midnight clocks and notice issuance (MOON).Designed Not builtC0580
REQ-0309The system shall record coverage with multiple payers, priority order and eligibility verification (X12 270/271, real-time and batch).Designed Not builtC0581
REQ-0310The system shall capture required notices and acknowledgments (NPP, consent to treat, financial policy, IM, MOON, ABN) with signature and delivery proof.Designed Not builtC0582
REQ-0311The system shall support electronic signature capture (pad, tablet) with evidence and hash of the displayed document.Designed Not builtC0583
REQ-0312The system shall capture advance directive and code status with document link.Designed Not builtC0584
REQ-0313The system shall calculate patient estimates and Good Faith Estimates when charge data exist.Designed Not builtC0585
REQ-0314The system shall support financial clearance and financial assistance screening with sliding-fee schedules.Designed Not builtC0586
REQ-0315The system shall track waiting-room status and arrival-to-rooming workflow with display boards that show minimal identifiers.Designed Not builtC0587
REQ-0316The system shall issue wristbands and labels (Code 128 / 2D) with two identifiers and allergy alert marks.Pilot Partly builtC0588
REQ-0317The system shall produce After-Visit Summaries and discharge instructions in the patient's language.Designed Not builtC0589
REQ-0318The system shall support visitor management and visit restrictions.Designed Not builtC0590
REQ-0319The system shall support patient transport requests and tracking inside the facility.Designed Not builtC0591
REQ-0320The system shall audit all registration edits with old/new values encrypted.Pilot Partly builtC0592
REQ-0321The system shall run front-end claim edits at registration.Designed Not builtC0593
REQ-0322The system shall support Brazil SUS registration data (AIH/BPA), CNS lookup and CADSUS integration and equivalent country adapters.Designed Not builtC0594

Scheduling and access management (15)

Appointments, resources, waitlists, reminders.

IDRequirementPilot statusAnswer
REQ-0351The system shall provide provider templates, visit types, durations and overbooking rules with effective dating.Designed Not builtC0595
REQ-0352The system shall schedule multi-resource appointments (provider, room, equipment).Designed Not builtC0596
REQ-0353The system shall support recurring series, group appointments and block scheduling with release rules.Designed Not builtC0597
REQ-0354The system shall provide waitlist management with automatic fill.Designed Not builtC0598
REQ-0355The system shall provide online self-scheduling through the patient portal/wallet with rules per visit type.Designed Not builtC0599
REQ-0356The system shall send reminders by SMS, email, voice, push and WhatsApp where allowed, honoring per-channel contact consent.Designed Not builtC0600
REQ-0357The system shall check referral and authorization requirements before scheduling.Designed Not builtC0601
REQ-0358The system shall detect double booking and require override permission with reason.Designed Not builtC0602
REQ-0359The system shall enforce no-show and late-cancel policies with configurable rules.Designed Not builtC0603
REQ-0360The system shall publish and consume HL7 SIU S12-S26 and FHIR Appointment/Schedule/Slot.Designed Not builtC0604
REQ-0361The system shall provide schedule utilization and access analytics (third-next-available, fill rate).Designed Not builtC0605
REQ-0362The system shall support recall and preventive-care outreach lists.Designed Not builtC0606
REQ-0363The system shall support telehealth visit scheduling and link generation.Designed Not builtC0607
REQ-0364The system shall support provider absence management with automatic rebooking suggestions.Designed Not builtC0608
REQ-0365The system shall provide a regulation-queue adapter for national referral systems such as SISREG.Designed Not builtC0609

Clinical documentation and the chart (37)

Problem-oriented chart, notes, templates, signatures, amendments.

IDRequirementPilot statusAnswer
REQ-0401The system shall present a patient header/banner with identifiers, age, sex, allergies, code status, isolation and restricted flags on every chart screen.Pilot Partly builtC0610
REQ-0402The system shall provide a chart summary/snapshot with problems, meds, allergies, vitals, recent results and care team.Pilot Partly builtC0611
REQ-0403The system shall manage the problem list (active/resolved/inactive) with SNOMED CT or ICD-10-CM/CIE-10 coding and verification status.Designed Placeholder onlyC0612
REQ-0404The system shall record medical, surgical, family and social history with coded and free-text entries.Designed Not builtC0613
REQ-0405The system shall manage allergy/intolerance lists with reaction, severity, criticality and explicit no-known-allergies assertion.Designed Placeholder onlyC0614
REQ-0406The system shall record vital signs and flowsheets with LOINC-mapped rows and UCUM units.Pilot Partly builtC0615
REQ-0407The system shall support clinical notes of all types in file 01 with structured sections and free text.Pilot Partly builtC0616
REQ-0408The system shall provide templates, smart phrases and macros with variable substitution that cannot execute code.Designed Not builtC0617
REQ-0409The system shall support voice dictation with review before filing; audio is not retained beyond policy.Designed Not builtC0618
REQ-0410The system shall optionally support ambient AI documentation as draft notes under section AI.Designed Not builtC0619
REQ-0411The system shall support copy-forward with visible change highlighting and provenance.Designed Not builtC0620
REQ-0412The system shall support note signing, cosigning, attestation and teaching-physician statements.Designed Not builtC0621
REQ-0413The system shall support addenda, amendments and entered-in-error marking without deleting original content.Designed Not builtC0622
REQ-0414The system shall support late entries with both event time and entry time displayed.Designed Not builtC0623
REQ-0415The system shall capture structured data through discrete forms and questionnaires (FHIR Questionnaire/SDC).Designed Not builtC0624
REQ-0416The system shall provide document management: scanning, indexing, OCR, categories, encounter links and fax intake.Designed Not builtC0625
REQ-0417The system shall capture clinical photographs and wound images with annotation, measurement scale and consent.Designed Not builtC0626
REQ-0418The system shall provide body diagrams with vector annotations.Designed Not builtC0627
REQ-0419The system shall provide validated clinical calculators with versioned formulas.Designed Not builtC0628
REQ-0420The system shall provide a clinical inbox with pooled and delegated queues for results, messages, refill requests and referrals; every item has an owner.Designed Not builtC0629
REQ-0421The system shall generate result-notification letters and templates.Designed Not builtC0630
REQ-0422The system shall support letters, forms and correspondence templates and FMLA/disability forms.Designed Not builtC0631
REQ-0423The system shall generate and consume C-CDA documents and represent notes as FHIR DocumentReference/Composition.Designed Not builtC0632
REQ-0424The system shall support Open Notes / Cures Act sharing with exceptions and documented reasons.Designed Not builtC0633
REQ-0425The system shall segment psychotherapy notes and 42 CFR Part 2 records into separate compartments.Designed Not builtC0634
REQ-0426The system shall document interpreter use.Designed Not builtC0635
REQ-0427The system shall support clinical coding of encounters (ICD-10-CM, CPT/HCPCS, CIE-10 and country equivalents) with encoder integration.Designed Not builtC0636
REQ-0428The system shall provide a longitudinal timeline view across encounters and external sources.Pilot Partly builtC0637
REQ-0429The system shall support external/outside record reconciliation and incorporation.Designed Not builtC0638
REQ-0430The system shall provide assessments and scores (pain, falls, pressure injury, nutrition) with versioned instruments.Designed Not builtC0639
REQ-0431The system shall provide care team management and patient-provider relationships that drive access policy.Pilot Partly builtC0640
REQ-0432The system shall provide patient lists with minimum-necessary query enforcement.Pilot Partly builtC0641
REQ-0433The system shall provide rounding, handoff and sign-out tools.Designed Not builtC0642
REQ-0434The system shall provide pathways/protocols and order sets under clinical governance.Designed Not builtC0643
REQ-0435The system shall provide CDI query and response workflows.Designed Not builtC0644
REQ-0436The system shall support digital signature with ICP-Brasil certificates where the profile requires.Designed Not builtC0645
REQ-0437The system shall provide patient education library integration with language and reading-level metadata.Designed Not builtC0646

Orders and CPOE (19)

Order entry, sets, communication, tracking, prior authorization.

IDRequirementPilot statusAnswer
REQ-0501The system shall provide CPOE for medications, labs, imaging, procedures, referrals, nursing, diet, therapy, DME, blood and isolation.Designed Placeholder onlyC0647
REQ-0502The system shall require ordering authority by role and licensure and shall restrict order types per role.Pilot Partly builtC0648
REQ-0503The system shall support order sets, panels, quick orders and preference lists with versioning.Designed Not builtC0649
REQ-0504The system shall support ask-at-order-entry questions.Designed Not builtC0650
REQ-0505The system shall support verbal/telephone orders with read-back and cosign deadlines.Designed Not builtC0651
REQ-0506The system shall support protocol/standing/pended/future/recurring orders.Designed Not builtC0652
REQ-0507The system shall track order status from ordered to final with a defined state machine.Designed Not builtC0653
REQ-0508The system shall emit and consume HL7 v2 orders/results and FHIR ServiceRequest/Task/DiagnosticReport.Designed Not builtC0654
REQ-0509The system shall check duplicate orders, medical necessity and authorization requirements.Designed Not builtC0655
REQ-0510The system shall show appropriate-use criteria for advanced imaging where required.Designed Not builtC0656
REQ-0511The system shall optionally display cost of care at order entry.Designed Not builtC0657
REQ-0512The system shall reconcile orders at transfer, admission and discharge.Designed Not builtC0658
REQ-0513The system shall verify consent before blood product orders.Designed Not builtC0659
REQ-0514The system shall support referral/consult orders with closed-loop tracking.Designed Not builtC0660
REQ-0515The system shall support DME/home-health/SNF orders with face-to-face documentation.Designed Not builtC0661
REQ-0516The system shall support electronic lab ordering to external networks and bi-directional interfaces.Designed Not builtC0662
REQ-0517The system shall support electronic prior authorization (X12 278, Da Vinci PAS, NCPDP ePA) and real-time prescription benefit.Designed Not builtC0663
REQ-0518The system shall provide order entry on approved mobile devices.Designed Not builtC0664
REQ-0519The system shall mark AI-generated order suggestions as drafts requiring explicit signature.Designed Not builtC0665

Results management and diagnostic reporting (10)

Result review, acknowledgment, critical values, trending.

IDRequirementPilot statusAnswer
REQ-0601The system shall provide a results inbox with acknowledgment and sign-off tracking.Pilot Partly builtC0666
REQ-0602The system shall record critical-value notification with read-back and callback documentation.Pilot Partly builtC0667
REQ-0603The system shall route results to ordering, PCP and covering providers with rules.Designed Not builtC0668
REQ-0604The system shall track pending results at discharge and assign owners.Designed Not builtC0669
REQ-0605The system shall release results to the patient per Cures Act rules with configurable delay for sensitive types.Designed Not builtC0670
REQ-0606The system shall provide trending/graphing, reference ranges by age/sex and delta checks.Designed Not builtC0671
REQ-0607The system shall incorporate outside lab results discretely with LOINC mapping.Designed Not builtC0672
REQ-0608The system shall link reports to images (DiagnosticReport to ImagingStudy).Designed Not builtC0673
REQ-0609The system shall support pathology synoptic reporting and genomic/molecular results.Designed Not builtC0674
REQ-0610The system shall ingest point-of-care results with operator and QC checks.Designed Not builtC0675

Pharmacy, medication management and e-prescribing (22)

Medication orders, verification, dispensing, eMAR, prescribing, controlled substances.

IDRequirementPilot statusAnswer
REQ-0701The system shall provide medication ordering with RxNorm coding, dose/route/frequency/indication and duration.Designed Not builtC0676
REQ-0702The system shall check drug-drug, drug-allergy, duplicate therapy, dose range, renal/hepatic and age/weight rules using a licensed knowledge base.Designed Not builtC0677
REQ-0703The system shall support weight/BSA and pediatric dosing calculators with recency checks on weight.Designed Not builtC0678
REQ-0704The system shall provide pharmacist verification queues.Designed Not builtC0679
REQ-0705The system shall provide eMAR with barcode medication administration.Designed Placeholder onlyC0680
REQ-0706The system shall integrate IV pumps and dispensing cabinets via standards.Designed Not builtC0681
REQ-0707The system shall maintain medication lists with reconciliation at transitions.Pilot Partly builtC0682
REQ-0708The system shall retrieve external medication history (NCPDP RxHistory / Surescripts).Designed Not builtC0683
REQ-0709The system shall e-prescribe via NCPDP SCRIPT with version negotiation between 2017071 and 2023011 and shall use 2023011 exclusively for Part D by 2028-01-01.Designed Not builtC0684
REQ-0710The system shall support EPCS with DEA-required identity proofing, two-factor signing and audit.Designed Not builtC0685
REQ-0711The system shall query PDMP as required and record purpose.Designed Not builtC0686
REQ-0712The system shall check formulary/benefit (NCPDP F&B v60) and real-time benefit (RTPB v13).Designed Not builtC0687
REQ-0713The system shall support controlled-substance inventory, witness waste and diversion analytics.Designed Not builtC0688
REQ-0714The system shall support IV compounding, hazardous drug and non-sterile records.Designed Not builtC0689
REQ-0715The system shall support pharmacy inventory with par levels and recalls.Designed Not builtC0690
REQ-0716The system shall support antimicrobial stewardship, MTM and ADE reporting.Designed Not builtC0691
REQ-0717The system shall support specialty and discharge pharmacy workflows and refill requests.Designed Not builtC0692
REQ-0718The system shall support Brazil controlled prescriptions and digital prescribing rules.Designed Not builtC0693
REQ-0719The system shall support chemotherapy regimens with dose banding and independent double check.Designed Not builtC0694
REQ-0720The system shall support anticoagulation, insulin and TPN protocols.Designed Not builtC0695
REQ-0721The system shall support 340B tracking and split billing where applicable.Designed Not builtC0696
REQ-0722The system shall support drug shortage substitutions.Designed Not builtC0697

Clinical decision support and alerts (10)

Rules, alerts, models, governance.

IDRequirementPilot statusAnswer
REQ-0801The system shall provide rule-based alerts (drug, allergy, duplicate, dose, best-practice) with interruptive and non-interruptive modes.Designed Not builtC0698
REQ-0802The system shall record alert overrides with coded reasons and provide alert analytics.Designed Not builtC0699
REQ-0803The system shall support CDS Hooks and FHIR clinical reasoning (PlanDefinition, ActivityDefinition, CQL).Designed Not builtC0700
REQ-0804The system shall provide early-warning scores (NEWS, MEWS) and sepsis screening with model version display.Designed Not builtC0701
REQ-0805The system shall expose decision-support intervention source attributes for predictive models as required for certification.Designed Not builtC0702
REQ-0806The system shall provide health-maintenance reminders and immunization forecasting (CDC CDSi).Designed Not builtC0703
REQ-0807The system shall provide sound-alike/look-alike (Tall Man) display.Designed Not builtC0704
REQ-0808The system shall support pharmacogenomic decision support.Designed Not builtC0705
REQ-0809The system shall provide suicide risk screening alerts, SDOH screening and radiation dose alerts.Designed Not builtC0706
REQ-0810The system shall govern AI/predictive tools with a model inventory, validation and monitoring before enablement.Designed Not builtC0707

Nursing and inpatient care (10)

Nursing documentation, tasks, restraints, LDA, handoff.

IDRequirementPilot statusAnswer
REQ-0901The system shall provide nursing assessment flowsheets and care plans coded with NANDA-I/NIC/NOC or local equivalents.Designed Not builtC0708
REQ-0902The system shall provide task lists by due time with overdue escalation.Designed Not builtC0709
REQ-0903The system shall integrate bedside devices (monitors, ventilators, ECG) via IEEE 11073/IHE PCD-01.Designed Not builtC0710
REQ-0904The system shall document restraint/seclusion per regulatory requirements including time limits and monitoring.Designed Not builtC0711
REQ-0905The system shall document intake/output, LDA, wounds, falls and isolation.Pilot Partly builtC0712
REQ-0906The system shall provide shift handoff reports.Designed Not builtC0713
REQ-0907The system shall support virtual nursing/sitter sessions without retaining video by default.Designed Not builtC0714
REQ-0908The system shall support electronic whiteboards with minimal identifiers.Designed Not builtC0715
REQ-0909The system shall support case management, discharge planning and utilization review tools.Designed Not builtC0716
REQ-0910The system shall support SEP-1 and inpatient eCQM abstraction.Designed Not builtC0717

Emergency department (9)

Triage, tracking, ED workflows, time metrics.

IDRequirementPilot statusAnswer
REQ-1001The system shall provide ED triage using ESI, CTAS or Manchester with site-selected scale.Designed Not builtC0718
REQ-1002The system shall provide an ED tracking board with configurable statuses and time clocks.Designed Not builtC0719
REQ-1003The system shall support provider-in-triage, fast-track and quick registration.Designed Not builtC0720
REQ-1004The system shall provide ED order sets for chest pain, stroke, sepsis, trauma.Designed Not builtC0721
REQ-1005The system shall track stroke and STEMI time metrics.Designed Not builtC0722
REQ-1006The system shall ingest EMS prehospital data (NEMSIS/ePCR).Designed Not builtC0723
REQ-1007The system shall document EMTALA screening and transfer.Designed Not builtC0724
REQ-1008The system shall provide ED throughput analytics.Designed Not builtC0725
REQ-1009The system shall support Brazilian Pronto Atendimento risk classification.Designed Not builtC0726

Inpatient, critical care, surgery and anesthesia (11)

Hospital medicine, ICU, periop.

IDRequirementPilot statusAnswer
REQ-1101The system shall support admission H&P, hospital course auto-summary and discharge summary workflows.Designed Not builtC0727
REQ-1102The system shall support critical care flowsheets, ICU scores and bundles.Designed Not builtC0728
REQ-1103The system shall integrate telemetry/ECG alarm management.Designed Not builtC0729
REQ-1104The system shall support ECMO, CRRT and dialysis documentation.Designed Not builtC0730
REQ-1105The system shall support transplant and palliative documentation.Designed Not builtC0731
REQ-1106The system shall support surgical case booking, preference cards, counts, time-outs and intraoperative records.Designed Not builtC0732
REQ-1107The system shall track implants with UDI.Designed Not builtC0733
REQ-1108The system shall support operative notes with synoptic templates and anesthesia records with device integration.Designed Not builtC0734
REQ-1109The system shall support PACU documentation with recovery scores.Designed Not builtC0735
REQ-1110The system shall support OR scheduling optimization and block utilization analytics.Designed Not builtC0736
REQ-1111The system shall support sterile processing instrument tracking integration.Designed Not builtC0737

Radiology, imaging, PACS/RIS and DICOM (14)

Ordering to reporting for imaging; on-site image store.

IDRequirementPilot statusAnswer
REQ-1201The system shall provide RIS worklists, protocoling and reading queues.Designed Not builtC0756
REQ-1202The system shall provide DICOM Modality Worklist and MPPS for modalities.Designed Not builtC0757
REQ-1203The system shall receive DICOM C-STORE, support C-FIND/C-MOVE/C-GET and Storage Commitment over TLS with AE allow-lists.Designed Not builtC0758
REQ-1204The system shall implement DICOMweb QIDO-RS, WADO-RS, STOW-RS and UPS-RS.Designed Not builtC0759
REQ-1205The system shall store DICOM SR, RDSR, GSPS and KOS objects and render them.Designed Not builtC0760
REQ-1206The system shall reconcile patient identity between modality and ADT (IHE PIR) before filing.Designed Not builtC0761
REQ-1207The system shall provide a zero-footprint enterprise viewer inside the terminal live feed.Designed Not builtC0762
REQ-1208The system shall integrate VNA/PACS and image exchange (CD import, cloud share) with quarantine and AV scanning.Designed Not builtC0763
REQ-1209The system shall support structured reporting (RSNA RadReport, BI-RADS and other -RADS systems) and follow-up recommendation tracking.Designed Not builtC0764
REQ-1210The system shall record radiation dose and provide dose alerts.Designed Not builtC0765
REQ-1211The system shall support mammography tracking and MQSA reporting.Designed Not builtC0766
REQ-1212The system shall communicate critical imaging results with closed-loop acknowledgment.Designed Not builtC0767
REQ-1213The system shall support teleradiology and AI image triage as clearly labeled decision support.Designed Not builtC0768
REQ-1214The system shall support contrast, pregnancy and renal screening at imaging scheduling.Designed Not builtC0769

Laboratory, pathology, microbiology and blood bank (14)

LIS functions on-site.

IDRequirementPilot statusAnswer
REQ-1301The system shall provide lab order entry with specimen requirements and AOE.Designed Not builtC0770
REQ-1302The system shall support barcode specimen collection, accessioning, tracking and chain of custody.Designed Not builtC0771
REQ-1303The system shall interface with analyzers via ASTM E1381/E1394 (LIS2-A2) and CLSI AUTO/POCT1.Designed Not builtC0772
REQ-1304The system shall provide autoverification, delta checks, reflex testing and add-on orders under lab-director-approved rules.Designed Not builtC0773
REQ-1305The system shall support QC (Levey-Jennings, Westgard) and proficiency testing.Designed Not builtC0774
REQ-1306The system shall support CLIA/CAP/COLA compliance records.Designed Not builtC0775
REQ-1307The system shall support microbiology workflows with AST/MIC interpretation and antibiogram.Designed Not builtC0776
REQ-1308The system shall support anatomic pathology (gross, histology, cytology, frozen) and digital pathology integration.Designed Not builtC0777
REQ-1309The system shall support molecular/genomic workflows and variant reporting with HGVS/HGNC.Designed Not builtC0778
REQ-1310The system shall support blood bank typing, crossmatch, inventory, ISBT 128 labeling and bedside verification.Designed Not builtC0779
REQ-1311The system shall support outreach and send-out lab management.Designed Not builtC0780
REQ-1312The system shall report to public health (ELR, newborn screening).Designed Not builtC0781
REQ-1313The system shall maintain the lab test catalog with LOINC mappings, and lab inventory, workload and TAT dashboards.Designed Not builtC0782
REQ-1314The system shall support HL7 LOI/LRI and eDOS profiles.Designed Not builtC0783

Cardiology, oncology, obstetrics, pediatrics, behavioral, dental, ophthalmology, rehab (9)

Specialty content packs.

IDRequirementPilot statusAnswer
REQ-1401The system shall support ECG management, cath lab, echo, device clinic and registry data collection.Designed Not builtC0738
REQ-1402The system shall support oncology regimens, staging (AJCC), infusion scheduling, radiation oncology integration, tumor boards and cancer registry feeds.Designed Not builtC0739
REQ-1403The system shall support prenatal, labor and delivery, fetal monitoring, newborn and postpartum documentation.Designed Not builtC0740
REQ-1404The system shall support pediatrics: growth charts, immunization schedule, weight-based safeguards, developmental screening and adolescent confidentiality.Designed Not builtC0741
REQ-1405The system shall support Latin American perinatal records (Historia Clínica Perinatal CLAP, Cartão da Gestante).Designed Not builtC0742
REQ-1406The system shall support behavioral health: safety plans, group therapy, measurement-based care, involuntary hold documentation and 42 CFR Part 2 consent management.Designed Not builtC0743
REQ-1407The system shall support dental charting with tooth numbering and CDT coding.Designed Not builtC0744
REQ-1408The system shall support ophthalmology exam data and device integration.Designed Not builtC0745
REQ-1409The system shall support rehabilitation, home health, hospice and long-term care assessments (IRF-PAI, OASIS, MDS).Designed Not builtC0746

Population health, registries and quality measurement (5)

Cohorts, registries, quality reports.

IDRequirementPilot statusAnswer
REQ-1501The system shall build cohorts and registries from structured data without exporting identifiers unless authorized.Designed Not builtC0751
REQ-1502The system shall compute eCQMs with CQL and value sets and produce QRDA I/III.Designed Not builtC0752
REQ-1503The system shall provide risk stratification and gaps-in-care lists.Designed Not builtC0753
REQ-1504The system shall support immunization registry reporting and query.Designed Not builtC0754
REQ-1505The system shall produce the reports in the reference catalogs through the report engine using registry-defined report definitions.Designed Not builtC0755

Care management, care coordination and referral (4)

Referral loops, care plans, community resources.

IDRequirementPilot statusAnswer
REQ-1601The system shall manage referrals with loop closure and status tracking across internal and external recipients.Designed Not builtC0747
REQ-1602The system shall support care plans, care teams and shared goals with patient view.Designed Not builtC0748
REQ-1603The system shall support SDOH screening, community resource referral and Gravity value sets.Designed Not builtC0749
REQ-1604The system shall support transitions of care (C-CDA/Direct/HIE) with reconciliation.Designed Not builtC0750

Patient portal, wallet and telehealth (8)

Patient-facing surfaces (app, portal, wallet).

IDRequirementPilot statusAnswer
REQ-1701The system shall provide a patient portal and wallet app for records view, messages, scheduling, forms, payments, proxy access and consent.Designed Not builtC0802
REQ-1702The system shall present a patient-visible access history derived from ledger audit batches.Designed Not builtC0803
REQ-1703The system shall support patient-initiated records requests with identity verification and automatic fulfilment through the consent flow.Designed Not builtC0804
REQ-1704The system shall support proxy/guardian access with scoped views and age-based transitions (adolescent).Designed Not builtC0805
REQ-1705The system shall support secure telehealth video visits (WebRTC) with recording off by default and consent capture.Designed Not builtC0806
REQ-1706The system shall support remote patient monitoring and wearable data intake flagged as patient-reported.Designed Not builtC0807
REQ-1707The system shall provide SMART Health Cards / Links for vaccination and summary data.Designed Not builtC0808
REQ-1708The system shall support patient payment (card, PIX, local methods) via certified processors that never store card data in the record.Designed Not builtC0809

Revenue cycle, billing and payer connectivity (7)

Charges, claims, remittance, denials.

IDRequirementPilot statusAnswer
REQ-1801The system shall capture charges from documentation and orders with charge master validation.Designed Not builtC0810
REQ-1802The system shall generate and submit X12 837P/837I/837D with SNIP-style edits and receive 999/277CA/835.Designed Not builtC0811
REQ-1803The system shall support 270/271, 276/277 and 278 transactions.Designed Not builtC0812
REQ-1804The system shall post remittances (835), manage denials/appeals and patient statements.Designed Not builtC0813
REQ-1805The system shall support Brazil TISS XML guides with digital signature and SUS billing; Colombia RIPS/FEV/CUV; Mexico CFDI; other country billing adapters.Designed Not builtC0814
REQ-1806The system shall support price transparency files and Good Faith Estimates.Designed Not builtC0815
REQ-1807The system shall support payer-platform functions: contract modeling, eligibility, prior authorization APIs (CMS-0057-F).Designed Not builtC0816

Supply chain, HR and facilities (4)

Materials, staffing, credentialing, environment of care.

IDRequirementPilot statusAnswer
REQ-1901The system shall manage materials, inventory, par levels and implant/consignment tracking.Designed Not builtC0817
REQ-1902The system shall support GS1 barcodes (GTIN, SSCC, DataMatrix).Designed Not builtC0818
REQ-1903The system shall manage workforce credentialing, licensure, certifications and expiry alerts.Designed Not builtC0819
REQ-1904The system shall record environment-of-care logs, life-safety tests, equipment maintenance and radiation safety records.Designed Not builtC0820

Analytics, reporting and data warehouse (3)

Reports and dashboards under minimum necessary.

IDRequirementPilot statusAnswer
REQ-2001The system shall provide a report engine with role-limited definitions, scheduling and small-cell suppression.Designed Not builtC0821
REQ-2002The system shall provide operational dashboards (census, throughput, utilization, quality).Designed Not builtC0822
REQ-2003The system shall provide research/analytics extracts only as limited datasets or de-identified datasets under DUA and approval.Designed Not builtC0823

Interoperability and exchange (13)

Standards-based exchange (details in file 04).

IDRequirementPilot statusAnswer
REQ-2101The system shall provide an interface engine supporting MLLP/TCP, HTTPS, SFTP, SOAP and message queues with transformation, routing, retry and dead-letter queues.Designed Not builtC0784
REQ-2102The system shall implement the HL7 v2 message families and segments in file 04 with configurable profiles.Designed Not builtC0785
REQ-2103The system shall implement FHIR R4 (4.0.1) REST server, search, operations, US Core 6.1.0 profiles and SMART App Launch 2.0.0.Designed Not builtC0786
REQ-2104The system shall implement FHIR Bulk Data export subject to quorum approval and limiter rules.Designed Not builtC0787
REQ-2105The system shall create, receive and reconcile C-CDA R2.1 documents and support EHI export.Designed Not builtC0788
REQ-2106The system shall support IHE XDS.b, XCA, XCPD, PIX/PDQ, ATNA, MHD profiles.Designed Not builtC0789
REQ-2107The system shall support TEFCA (QHIN participant/subparticipant) using document query and Facilitated FHIR with UDAP security and Exchange Purpose codes.Designed Not builtC0790
REQ-2108The system shall support Carequality and CommonWell connectivity through a partner or direct implementation.Designed Not builtC0791
REQ-2109The system shall support Direct Secure Messaging.Designed Not builtC0792
REQ-2110The system shall support X12 and NCPDP transactions in file 04.Designed Not builtC0793
REQ-2111The system shall support DICOM, IEEE 11073, POCT1, ASTM device interfaces.Designed Not builtC0794
REQ-2112The system shall provide LatAm interfaces: RNDS (BR), IHCE/RDA (CO), NOM-024 (MX), RENIPRESS/SIS (PE), FONASA (CL), Receta electrónica (AR) as adapters.Designed Not builtC0795
REQ-2113The system shall provide conformance-tooling hooks (validators, ONC/Inferno, HL7 validator) in CI.Designed Not builtC0796

Security, privacy, consent, audit and access control (9)

See file 05; requirements repeated here as functional IDs.

IDRequirementPilot statusAnswer
REQ-2201The system shall enforce access as role AND relationship AND purpose AND context AND consent AND risk AND quota for every read, write, print and export.Pilot Partly builtC0879
REQ-2202The system shall support RBAC, ABAC and ReBAC with a central policy decision point and local enforcement points.Pilot Partly builtC0880
REQ-2203The system shall provide break-glass emergency access with reason code, time limit, notifications and mandatory review.Pilot Partly builtC0881
REQ-2204The system shall segment sensitive data into compartments with separate keys and policies (psychotherapy, SUD, HIV/STI, reproductive health, genetic, minors, VIP).Designed Not builtC0882
REQ-2205The system shall provide HIPAA privacy operations: accounting of disclosures, ROI, amendments, restrictions, breach workflow.Pilot Partly builtC0883
REQ-2206The system shall provide patient-facing access reports and consent directives (opt-in/opt-out for HIE, research).Designed Not builtC0884
REQ-2207The system shall support data segmentation for privacy (HL7 DS4P labels).Designed Not builtC0885
REQ-2208The system shall provide de-identification, pseudonymization and tokenization services.Designed Not builtC0886
REQ-2209The system shall support LGPD, GDPR, HIPAA and Peru Ley 29733 configurations including subject-rights workflows.Designed Not builtC0887

Identity, authentication and single sign-on (7)

FIDO2, badge, SSO, provisioning.

IDRequirementPilot statusAnswer
REQ-2251The system shall authenticate workforce with FIDO2 hardware key plus badge (or PIN plus badge) and phishing-resistant flows.Pilot Partly builtC0888
REQ-2252The system shall enforce session binding, idle timeouts, walk-away lock and single concurrent session per identity.Pilot Partly builtC0889
REQ-2253The system shall integrate with directory services via SAML/OIDC/LDAP/SCIM for provisioning where a customer has one.Designed Not builtC0890
REQ-2254The system shall support badge tap-and-go (NFC/UWB) authentication and CCOW-style context sharing.Designed Not builtC0891
REQ-2255The system shall verify provider identity (NPI, DEA, licence) at credentialing.Designed Not builtC0892
REQ-2256The system shall support patient authentication via wallet passkeys and government IdPs.Designed Not builtC0893
REQ-2257The system shall support service account authorization with mTLS SVIDs.Designed Not builtC0894

Infrastructure, downtime, administration and support (9)

See file 07.

IDRequirementPilot statusAnswer
REQ-2301The system shall run on the single-cabinet on-site server with local operation independent of the internet.Designed Placeholder onlyC0857
REQ-2302The system shall provide downtime mode with read-only emergency data set and paper downtime forms.Designed Not builtC0858
REQ-2303The system shall provide backup, restore and DR per file 07 tiers.Designed Not builtC0859
REQ-2304The system shall provide interface monitoring, application performance monitoring and audit dashboards.Designed Not builtC0860
REQ-2305The system shall support scheduled maintenance with signed updates and rollback.Designed Not builtC0861
REQ-2306The system shall provide data migration tooling: MPI cleanup, C-CDA/HL7 replay, chart abstraction, archive viewer.Designed Not builtC0862
REQ-2307The system shall provide training environments, proficiency tracking and support portals.Designed Not builtC0863
REQ-2308The system shall support printing and label infrastructure (Zebra ZPL, PDF, direct-attached printers).Designed Not builtC0864
REQ-2309The system shall support peripherals: barcode scanners, badge readers, signature pads, card readers, cameras where allowed.Designed Not builtC0865

Mobile, bedside and point-of-care (4)

Tablets and handhelds.

IDRequirementPilot statusAnswer
REQ-2351The system shall provide sealed tablet terminals as thin clients displaying a server-rendered live feed with no persistent data.Pilot Partly builtC0866
REQ-2352The system shall provide bedside barcode scanning and mobile documentation on approved devices with server-rendered display.Designed Not builtC0867
REQ-2353The system shall support offline-first capture only through the on-site server and local wired/wireless LAN; no PHI is stored on mobile devices.Designed Not builtC0868
REQ-2354The system shall support mobile secure messaging and push notifications through the system-wide messaging service.Pilot Partly builtC0869

AI, ambient documentation and automation (4)

Draft-only AI.

IDRequirementPilot statusAnswer
REQ-2401AI features shall be off by default, enabled per facility with model inventory entry and validation evidence.Designed Not builtC0870
REQ-2402AI outputs shall be labeled, cited to source elements, and never auto-filed or auto-signed.Designed Not builtC0871
REQ-2403AI inference shall run on-site or in a customer-approved region; PHI shall not be used to train models without separate written approval.Designed Not builtC0872
REQ-2404The system shall log AI inputs/outputs by reference hash and model version.Designed Not builtC0873

Research and clinical trials (2)

IRB, consent, trials.

IDRequirementPilot statusAnswer
REQ-2451The system shall support research consent (eConsent), IRB documents, participant recruitment, CTMS integration, biospecimen tracking and clinical-trial billing separation.Designed Not builtC0824
REQ-2452The system shall support research datasets (limited/de-identified/OMOP) under DUA.Designed Not builtC0825

Public health reporting (3)

Registries and surveillance.

IDRequirementPilot statusAnswer
REQ-2501The system shall support eCR (eICR/RR), ELR, syndromic surveillance, IIS, cancer, trauma, stroke, cardiac, PDMP, NHSN, vital records and NEMSIS reporting as configured by jurisdiction.Designed Not builtC0826
REQ-2502The system shall receive HAN/public-health alerts.Designed Not builtC0827
REQ-2503The system shall support DHIS2 aggregate export (ADX/DXF2) and OpenMRS/Bahmni/FHIR exchange for low-resource deployments.Designed Not builtC0828

Regulatory, compliance and certification support (3)

Compliance evidence.

IDRequirementPilot statusAnswer
REQ-2551The system shall maintain a compliance calendar of licenses, accreditations, certificates, drills and filings with expiry alerts.Designed Not builtC0829
REQ-2552The system shall support information-blocking exception documentation and Cures Act tooling.Designed Not builtC0830
REQ-2553The system shall support ONC certification test data and real-world testing evidence.Designed Not builtC0831

Federated ledger, spheres, tokens, wallets, bridges (15)

Only hashes, consent and audit on the ledger.

IDRequirementPilot statusAnswer
REQ-3001The ledger shall store only: salted record commitments, consent tokens and metadata, audit batch roots, authority/transfer records, wallet and token state, node presence, alerts and tombstones. Patient content, names, national ids and raw clinical values shall never be written.Designed Not builtC0922
REQ-3002Each clinic or clinic network shall be one sphere with its own ledger channel, membership registry and governance keys.Designed Not builtC0923
REQ-3003The system shall implement the token types ID, ROLE, CONS, GRANT, XFER, BRG-A/BRG-B, NODE, ALERT, BG and DELEG with the semantics in design 11.5, all non-transferable except through protocol operations. [Recommended: types from design 11.5; owner must confirm the final list]Designed Not builtC0924
REQ-3004The system shall support mintable wallets of classes W-P, W-D, W-S, W-N, W-B, W-G with minting by quorum, identity binding, expiry and rate limits.Designed Not builtC0925
REQ-3005Sensitive ledger actions shall require multi-key corroboration by a role-diverse policy; the numeric threshold is [Open] (the design example is 2-of-{clinical lead, privacy officer, security officer}).Designed Not builtC0926
REQ-3006Bridges between spheres shall use exactly two mirrored bridge tokens with history on both sides, two-phase commit with time locks and defined failure states.Designed Not builtC0927
REQ-3007Session risk bands (0-3) may use keystroke cadence, location and timestamp; keystroke cadence shall be a review flag only and never a sole lockout trigger.Designed Not builtC0928
REQ-3008Consent tokens shall be signed by the patient wallet (or delegate) over canonical bytes including the hash of the rendered text and shall be revocable with immediate ledger effect.Designed Not builtC0929
REQ-3009Record commitments shall be H(salt‖digest) with per-record 128-bit+ random salts held off-ledger.Designed Not builtC0930
REQ-3010Patient pseudonyms shall be HMAC(K_sphere, id‖r_patient) so that destroying r_patient severs linkage.Designed Not builtC0931
REQ-3011Cryptographic erasure shall destroy DEK, salts and r_patient by quorum, write a tombstone and verify undecryptability.Designed Not builtC0932
REQ-3012The ledger client shall queue writes when the ledger is unreachable and append them in order on reconnect; care shall not depend on ledger availability.Designed Not builtC0933
REQ-3013Signature algorithm identifiers shall be carried in every ledger message to allow crypto agility including hybrid PQC.Designed Not builtC0934
REQ-3014Ledger technology is baseline Hyperledger Fabric; the system shall isolate the ledger behind a service interface so that a signed hash-chained log with threshold anchors can replace it for single-owner spheres.Designed Not builtC0935
REQ-3015Home nodes and node presence tokens shall provide liveness attestation and out-of-schedule flagging to all nodes.Designed Not builtC0936

Sync, backup, read limiter and safe degradation (14)

Cloud sync and clinic-to-clinic sync; limiter; pause.

IDRequirementPilot statusAnswer
REQ-3101The on-site database shall be the operational primary; the cloud copy is an encrypted backup replica.Designed Not builtC0937
REQ-3102The sync agent shall produce signed, hash-chained, encrypted change bundles with gapless sequence numbers, replay protection and resumable upload.Designed Not builtC0938
REQ-3103The sync pathway shall support cloud sync and, where allowed by profile and consent, clinic-to-clinic sync.Designed Not builtC0939
REQ-3104A read-side limiter on a node en route to the server shall limit reads and pulls (not writes) using oscillating time windows. Window length, oscillation pattern and per-role/per-terminal quotas are [Open].Designed Not builtC0940
REQ-3105Tripping the limiter shall pause only cloud sync and clinic-to-clinic sync; local operation shall continue unaffected.Designed Not builtC0941
REQ-3106Any integrity alarm shall also pause sync (safe-degrade).Designed Not builtC0942
REQ-3107Resuming sync after a pause shall require multi-key corroboration and an audit entry.Designed Not builtC0943
REQ-3108The system shall pad bundle sizes and add batching jitter as a limited traffic-analysis countermeasure.Designed Not builtC0944
REQ-3109The system shall implement 3-2-1-1-0 backup tiers T0-T5 with immutable copy and offline copy, and shall anchor backup ranges on the ledger.Designed Not builtC0945
REQ-3110Restore shall run in an isolated environment with signature/chain verification and dual authorization for promotion.Designed Not builtC0946
REQ-3111Erasure requests shall propagate as tombstone bundles and key destruction events.Designed Not builtC0947
REQ-3112The scroll-rate lock shall require re-authentication when history-tab throughput exceeds the threshold [Open], computed server-side by information rendered, with different weights for HISTORY and RESULTS_TRIAGE.Designed Not builtC0948
REQ-3113Emergency mode shall relax history limits with full logging and no password prompt for patients in a declared emergency.Designed Not builtC0949
REQ-3114Bulk export by an individual shall be disabled; bulk operations shall run only through the quorum-approved Bulk Operation Workflow.Designed Not builtC0950

Offline behavior and printing (7)

Local operation, offline printing.

IDRequirementPilot statusAnswer
REQ-3201When sync or server transfer is down, the on-site main computer shall continue full clinical operation and shall be able to print records.Designed Not builtC0951
REQ-3202Printing shall use a wired, non-networked printer directly attached to the main computer (or print server on the closed LAN with no route outside).Designed Not builtC0952
REQ-3203Every print job shall be an audit event with user, hashed patient reference, time and terminal, queued locally while offline and appended to the ledger on reconnect.Designed Not builtC0953
REQ-3204Printed pages shall carry a watermark with user and time; the exact format is [Open].Designed Not builtC0954
REQ-3205Print rate limiting shall be enforced per user and terminal; values are [Open] (design example 50 prints/day per user, PROPOSED).Designed Not builtC0955
REQ-3206Printing of C4 compartment content shall require purpose and step-up.Designed Not builtC0956
REQ-3207Printed downtime reports shall be locked, sealed, logged and shredded on refresh.Designed Not builtC0957

On-site server, sealed terminals, hardware profile (7)

Physical system.

IDRequirementPilot statusAnswer
REQ-3301One closed-loop server per small hospital in a single cabinet; larger sites use multi-node clusters.Designed Not builtC0958
REQ-3302Terminals shall be sealed, input-only thin clients that store nothing and show a live feed, with waterproof rubber case, hinged waterproof keyboard, cooling fins and sleeved USB.Designed Not builtC0959
REQ-3303Terminal USB shall be electrically gated: allow-listed VID/PID, HID/CCID classes only, disabled in strict tier.Designed Not builtC0960
REQ-3304Camera-resistant screens shall use side-angle privacy filtering and the refresh-pattern measure; effectiveness against real cameras is untested and shall not be claimed until measured.Designed Not builtC0961
REQ-3305Terminals shall attest to the server at boot and per session (TPM/secure element) and refuse to render on mismatch.Designed Not builtC0962
REQ-3306Tamper switches shall zeroize keys and alert.Designed Not builtC0963
REQ-3307Equipment sold by AuroraMed shall be tracked as assets with serial, warranty and installed location.Designed Not builtC0964

Server-to-server transfer, three streams (5)

Secret-shared, decoy-padded transfer.

IDRequirementPilot statusAnswer
REQ-3401Server-to-server clinical data transfer shall use three simultaneous streams with interleaved decoy traffic and secret sharing so no single stream carries decryptable content.Designed Not builtC0965
REQ-3402The transfer shall use AES-256-GCM or ChaCha20-Poly1305 for data and hybrid X25519 + ML-KEM for key exchange.Designed Not builtC0966
REQ-3403The system shall document that decoys provide traffic-analysis resistance and not confidentiality or quantum resistance.Designed Not builtC0967
REQ-3404Transfer shall be authorized by an authority record and ledger transaction before any data leaves; the package commitment is recorded on both sides.Designed Not builtC0968
REQ-3405Transfer anomalies (stall, rate deviation, decoy ratio mismatch) shall abort the transfer and alert.Designed Not builtC0969

Analog timing layer (4)

Least mature component.

IDRequirementPilot statusAnswer
REQ-3501The analog timing layer, if built, shall be a separate optional module confined to one shielded room or booth with dual-key refreshing codes, delay paths and a home node.Designed Not builtC0970
REQ-3502Out-of-schedule signals shall be flagged to all nodes.Designed Not builtC0971
REQ-3503The layer shall never be the only lock, shall tolerate clock drift with configured windows, shall provide emergency break-glass, and shall use redundant home nodes.Designed Not builtC0972
REQ-3504Construction, refresh interval and delay values are [Open]; hardware is untested and no security claim shall be made about it.Designed Not builtC0973

Tiers, entitlements and commercial features (4)

Prices scale by tier; contact us for pricing.

IDRequirementPilot statusAnswer
REQ-3601The system shall implement entitlement records for the small, medium and large tiers (pricing not published).Designed Not builtC0853
REQ-3602The small tier shall be designed for about 20 patients maximum; how the limit is enforced (hard cap, soft alert) is [Open].Designed Not builtC0854
REQ-3603Tier shall not reduce legal-minimum privacy or security controls.Pilot Partly builtC0855
REQ-3604Support-reserve or support fee for small tier is [Open]; the software shall support recording a support fee if adopted.Designed Not builtC0856

Transport orders (Elyria integration) (5)

Only integration with Elyria Drone Shipping.

IDRequirementPilot statusAnswer
REQ-3701Clinics shall be able to create transport orders from a terminal for Elyria Drone Shipping, a separate company, through a defined external interface.Designed Not builtC0797
REQ-3702The order shall carry cargo class, origin, destination, requested time and handling requirements only; no PHI beyond the minimum needed (for example a specimen accession number) unless a BAA and profile allow.Designed Not builtC0798
REQ-3703Chain-of-custody events (pickup, handoff, delivery, temperature excursion, incident) shall be audit events and shown on the order.Designed Not builtC0799
REQ-3704Specimens and blood shall be enabled only when Elyria certified cold-chain capability is configured.Designed Not builtC0800
REQ-3705Results shall return to the clinic through the normal results interface.Designed Not builtC0801

System-wide platform services (4)

Common services.

IDRequirementPilot statusAnswer
REQ-3801The system shall provide a common event bus, job scheduler, notification service, document renderer (PDF/A) and search index, all running on-site.Pilot Partly builtC0849
REQ-3802Global search shall respect the read limiter, minimum necessary, and audit each query with criteria hashed.Designed Not builtC0850
REQ-3803The system shall provide a generic clinical timeline/event store from which patient-visible access history and audit reports are derived.Designed Not builtC0851
REQ-3804The system shall provide time synchronization (NTS/PPS) with skew alarms.Designed Not builtC0852

System-wide instant messaging (7)

Internal only.

IDRequirementPilot statusAnswer
REQ-4001Instant messaging shall be system-wide only: a message can be sent only to another workforce user or group of the same deployment/sphere. External addresses shall be impossible by construction.Pilot Built at MVP scopeC0977
REQ-4002The IM shall support direct, group/channel and patient-linked threads with membership rules per file 06.Pilot Partly builtC0978
REQ-4003The IM shall run on-site and work with the WAN down.Designed Placeholder onlyC0979
REQ-4004IM shall carry delivery, read and acknowledgment receipts and audit MSG_READ events.Pilot Partly builtC0980
REQ-4005IM attachments shall be scanned and limited by class; PHI images follow media rules.Designed Not builtC0981
REQ-4006IM retention shall be configurable by class within legal minimums; clinical content in patient-linked threads follows the clinical retention rule.Designed Not builtC0982
REQ-4007IM shall never suppress or delay a code alert; presence DND shall not affect code alerts.Pilot Built at MVP scopeC0983

Memo Desk (6)

In-house long-form correspondence inbox.

IDRequirementPilot statusAnswer
REQ-4101Memo Desk shall provide an internal long-form correspondence inbox with subject, rich text body, attachments, threads, folders, priority, due date and confidentiality level.Pilot Partly builtC0984
REQ-4102Memo Desk shall be internal only, signed by the sender session, and shall support shared pool inboxes with owners.Pilot Partly builtC0985
REQ-4103Memo Desk shall support formal notices with read-required acknowledgment recorded as a signature.Pilot Partly builtC0986
REQ-4104Memo Desk shall support legal hold on threads and retention classes.Designed Placeholder onlyC0987
REQ-4105Memo Desk shall support delegation and coverage rules with expiry.Designed Not builtC0988
REQ-4106Memo Desk shall not be used for urgent clinical notifications; it shall show a banner recommending the alert path for urgent items.Pilot Built at MVP scopeC0989

Code and clinical alert notifications (12)

Codes, critical results, emergency/urgent/standard pings.

IDRequirementPilot statusAnswer
REQ-4201The system shall support alert classes CODE, CLINICAL-CRITICAL (lab, imaging, blood), PING-EMERGENCY, PING-URGENT and PING-STANDARD with defined priority levels, ack rules and escalation.Pilot Built at MVP scopeC0990
REQ-4202Code alerts shall be configurable per facility: name, color, meaning, script, audience, sound, lockdown and integration actions. No code meaning shall be hard-coded as universal.Pilot Partly builtC0991
REQ-4203The system shall ship a default code library (Code Blue, Red, Pink, Purple, Silver, Active Shooter/Imminent Threat, Gray, Black, Orange, Yellow, Green, White, Triage, Amber, Rapid Response, Stroke, STEMI, Trauma, Sepsis, Massive Transfusion) as editable templates with no asserted universal meaning.Pilot Built at MVP scopeC0992
REQ-4204Imminent Threat / Active Shooter alerts shall have the highest priority, override all DND and screen locks, support silent (non-audible) mode, and be cancellable only by two authorized roles.Pilot Partly builtC0993
REQ-4205Code alerts shall work with the WAN and cloud unavailable, using only the on-site server and local network.Designed Placeholder onlyC0994
REQ-4206Critical lab/imaging/blood alerts shall reach the responsible clinician with acknowledgment tracking and escalation to an alternate if not acknowledged within the configured time [Open].Pilot Partly builtC0995
REQ-4207Alert delivery shall be at-least-once with de-duplication, ordered per alert, with delivery receipts, and shall fall back across channels (terminal, tablet, pager/radio/phone gateway where installed).Pilot Partly builtC0996
REQ-4208Alert payloads to non-terminal channels (pager, SMS) shall contain no PHI by default.Designed Not builtC0997
REQ-4209Alert actions shall be audit events: send, delivered, read, ack, escalate, cancel, all-clear.Pilot Built at MVP scopeC0998
REQ-4210The system shall support code drills that reuse the alert path with a DRILL flag and record timings.Pilot Partly builtC0999
REQ-4211Alert acknowledgment on sealed tablets shall be one-touch with accessibility support (large targets, audible, vibration where the device has it).Pilot Partly builtC1000
REQ-4212Alert policy changes shall require dual control and be versioned.Pilot Partly built

Privacy operations and patient rights (5)

LGPD/HIPAA/GDPR/Ley 29733 workflows.

IDRequirementPilot statusAnswer
REQ-4301The system shall provide workflows for access, correction/amendment, deletion/anonymization (crypto-erasure), portability, consent revocation, restriction/objection, information about sharing, and complaints.Designed Not builtC0911
REQ-4302The system shall target records-request fulfilment materially faster than the 72-hour norm through the consent flow; legal-review steps are not compressed.Designed Not builtC0912
REQ-4303Corrections shall be append-only amendments; the original remains for legal retention.Designed Not builtC0913
REQ-4304Breach workflow shall compute regulatory clocks from the active profile and track notifications.Designed Not builtC0914
REQ-4305The system shall maintain records of processing (ROPA) and support DPIA/RIPD artifacts.Designed Not builtC0915

Consent management (6)

Consent capture, scope, revocation, enforcement.

IDRequirementPilot statusAnswer
REQ-4401Consent shall be captured per purpose, data category, recipient class, duration and revocability, with the rendered text hash signed by the patient or authorized representative.Designed Not builtC0916
REQ-4402Consent shall be enforced at read time by the policy engine using the ledger consent state, with a local cached copy for offline use bounded by staleness limit [Open].Designed Not builtC0917
REQ-4403Consent shall support minors, guardians, proxies, HCPOA, deceased-patient personal representatives and adolescent confidential-care rules by profile.Designed Not builtC0918
REQ-4404Consent for 42 CFR Part 2 records, psychotherapy notes and reproductive-health-sensitive data shall be separate, purpose-specific and revocable.Designed Not builtC0919
REQ-4405The system shall provide a consent dashboard showing active consents, recipients, last access and revocation.Designed Not builtC0920
REQ-4406The LatAm strict tier shall use granular, specific, revocable consent per purpose and shall not rely on bundled consent.Designed Not builtC0921

Audit (7)

Audit trail, batching and anchoring.

IDRequirementPilot statusAnswer
REQ-4501Every access, change, print, export, consent, authentication, admin, alert and break-glass event shall generate an audit record with actor, role, terminal, purpose, patient pseudonym, object type, action, outcome, time and correlation id.Pilot Partly builtC0901
REQ-4502Audit records shall be hash-chained per node, batched into Merkle trees and the batch root anchored to the ledger at an interval [Open].Designed Not builtC0902
REQ-4503Audit storage shall be append-only with WORM tier and no update or delete interface for any role.Pilot Partly builtC0903
REQ-4504Audit shall provide a patient-facing accounting-of-disclosures and access-history view without exposing workforce personal data beyond profile rules.Pilot Partly builtC0904
REQ-4505Audit analytics shall detect snooping (VIP, coworker, neighbor, family), volume anomalies, off-hours access and repeated denials, producing review items with SLA.Designed Not builtC0905
REQ-4506Audit retention shall meet the longest applicable profile requirement; HIPAA documentation retention is 6 years [verify scope].Designed Not builtC0906
REQ-4507Auditors shall have read-only access by scoped, time-boxed role and their queries shall be audited.Pilot Partly builtC0907

Key management (6)

Hierarchy, HSM, rotation, ceremonies.

IDRequirementPilot statusAnswer
REQ-4601Keys shall follow the hierarchy Root -> Master KEK -> Sphere KEK -> Compartment KEK -> DEK with envelope encryption.Designed Not builtC0895
REQ-4602Root and master keys shall be in an HSM or equivalent secure element; large tier requires FIPS 140-validated HSM [verify level]; small tier may use a TPM-sealed or smartcard-based custody.Designed Not builtC0896
REQ-4603Key ceremonies shall be scripted, witnessed, logged, with split custody (Shamir) and documented recovery.Designed Not builtC0897
REQ-4604Keys shall be rotated on schedule and on compromise; rotation intervals are [Open] with design proposals.Designed Not builtC0898
REQ-4605Password hashing shall use Argon2id with at least 64 MiB memory and t>=3, or an equivalent tuned for the server.Designed Not builtC0899
REQ-4606Cryptographic modules shall support agility, including hybrid X25519+ML-KEM-768 for key establishment; ML-DSA signatures are optional and [Open].Designed Not builtC0900

Break-glass and emergency access (3)

BG tokens.

IDRequirementPilot statusAnswer
REQ-4701A break-glass access shall require an attested reason, produce an immediate audit and alert to the privacy officer, grant scope limited to the patient and duration <=4 h, and be reviewed within 24 h (72 h max).Designed Not builtC0908
REQ-4702Break-glass shall not allow bulk export, print of C4, or changes to security settings.Pilot Partly builtC0909
REQ-4703Break-glass shall work offline using locally signed BG tokens later reconciled to the ledger.Designed Not builtC0910

Downtime and business continuity (3)

Safe-mode ladder L0-L5.

IDRequirementPilot statusAnswer
REQ-4801The system shall provide the safe-mode ladder L0 normal through L5 paper/downtime, with defined entry conditions and UI banners.Designed Not builtC0974
REQ-4802The system shall generate downtime reports (census, MAR, orders, allergies, medications, problem list, code status, contact list) at schedule and on demand, to the directly attached printer.Designed Not builtC0975
REQ-4803The system shall provide back-entry of downtime paper records with reconciliation and audit flag.Designed Not builtC0976

Terminal and tablet user experience (5)

Thin-client UX.

IDRequirementPilot statusAnswer
REQ-4901Terminal UI shall be usable with gloves and quick-touch: min 48 px targets, high contrast, large-text mode, and no PHI cached in the browser.Pilot Partly builtC0874
REQ-4902The tablet UI shall provide role-based home, patient list, alert tray, messaging and Memo Desk access with an always-visible alert banner area.Pilot Partly builtC0875
REQ-4903The terminal shall show a live on-screen watermark (user, terminal, time) and lock on idle timers (2, 5, 10 min by area, PROPOSED).Designed Not builtC0876
REQ-4904The terminal UI shall support proximity badge tap-in/out and fast user switching within the session policy.Designed Not builtC0877
REQ-4905The UI shall support Spanish, Portuguese (BR) and English, with locale-specific date/number/units, and shall not machine-translate clinical content silently.Designed Not builtC0878
See the synthetic-data demo first.Request a demo