Governance · Clinical Data
The Data-Origin Policy
The operator’s EHR and eMAR remain the sole legal clinical record. Every value inside the operating record carries one of four origin labels, so nobody has to guess whether a number is clinical documentation, management context, a narrow direct entry, or something on its way back to a source system.
Version 1.0 · Adopted August 20, 2026 · Source review dated August 19, 2026
The single status table lives at /trust-center. Integration posture as of September 29, 2026: ingestion patterns are BUILT against test data or PLANNED on the dated roadmap. No connector to PointClickCare®, MatrixCare®, Yardi®, ALIS®, Eldermark®, PBJ/CMS, HL7/FHIR, or a clearinghouse is running in operator production today.
The rule this policy exists to prevent breaking
Clinical documentation, vital signs, changes in condition and medication administration are updated continuously through every shift by nurses and medication aides in the operator’s source systems. A second data-entry surface for those facts invites chart discrepancies, missed interventions and regulatory exposure during survey or litigation. SeniorCRE is not that surface.
1 · The system-of-record default
For a pilot and for production, the operator’s EHR and eMAR are the authoritative sources for the legal clinical record across these categories, unless a specific alternative has been agreed in writing:
- Resident demographics
- Medications and medication administration
- Assessments
- Care plans
- Appointments
- Vital signs
- Allergies
- Incident documentation
2 · The four labels
Every clinical value in the operating record is exactly one of these. The label travels with the value: on screen, in exports, and in the metrics the value feeds.
Label 1
Ingested clinical data
A value read from the operator’s source system of record — EHR, eMAR, pharmacy, payroll, accounting, CRM — and carried into the operating record without alteration.
- —SeniorCRE never edits, appends to, or overwrites the source value.
- —The value renders with its source system, source field, source date and ingestion date.
- —If the source and the operating record disagree, the source wins and the difference is queued as an exception.
Label 2
SeniorCRE operational annotation
Management and follow-up context created in SeniorCRE — an owner, a due date, an escalation note, a review decision — that supports action but is not part of the legal clinical record.
- —An annotation can never be read as clinical documentation.
- —Annotations are excluded from any export that represents the clinical record.
- —Annotations carry their author, role and timestamp.
Label 3
Controlled direct-entry data
A value entered in SeniorCRE for one narrowly defined workflow, agreed in writing with the operator, that has a documented reconciliation path back to the source system.
- —Permitted only where the operator has agreed the workflow, the limit and the reconciliation path in writing.
- —Every category not on that list is read-only in SeniorCRE — the entry surface is withdrawn, not left available.
- —Direct-entry values are visibly labelled wherever they appear, including in exports and diligence extracts.
Label 4
Write-back data
A value intended to be transferred into the operator’s source system through a defined, tested and auditable process.
- —Closed by default. No write-back path is enabled without an operator agreement, a tested process and a defined error and rollback procedure.
- —Every write-back attempt is logged with actor, payload, source response and outcome.
- —No write-back capability is available in operator production today.
3 · What this means in practice
- Why publish a policy instead of a feature?
- Because the risk is architectural, not cosmetic. An operating record that sits above an EHR can quietly become a second, incomplete clinical record. The four labels exist so that never happens by accident, and so an operator, a surveyor or a lender can ask which of the four a number is and get one answer.
- What is enforced today?
- The policy is adopted and published. Carrying the four labels as a non-nullable attribute on every clinical row, plus the per-category system-of-record register and the reconciliation and exception queues that make the labels provable, is registered backend work and is not enabled in operator production. Publication of the policy is not a claim that enforcement exists.
- Who decides what is authoritative?
- The operator. The policy default is that the operator’s EHR and eMAR are authoritative for the legal clinical record. A category moves off that default only by written agreement, with the workflow, the limit and the reconciliation path named.
- What happens when two systems disagree?
- The source system wins, the difference becomes an exception with an owner, and the correction is made in the system of record — not patched in the operating record. Who corrects, in which system, and how the correction propagates is stated in the pilot agreement before any clinical data moves.
4 · Status
This policy is adopted. The enforcement mechanics — origin labels as a non-nullable attribute on clinical rows, the per-category system-of-record register, source-to-target reconciliation, the exception queue and the write-back gate — are registered engineering work and are not enabled in operator production. No third-party clinical integration is in operator production today. Data crossover will not be described as complete until source-to-target reconciliation and clinical acceptance testing are documented.