Mark In Error

What is Mark In Error?

Mark In Error is SystmOne's primary method for correcting incorrect clinical entries. It flags entries as erroneous without deleting history — removing the entry from active clinical data while preserving a complete, permanent audit trail.

This page information supports: ISO 27789 ISO 27001 9.4.5 / 12.4 DKICT-V5

Permanent action

Mark In Error cannot be reversed once the record is saved. If the marking itself was a mistake, use the Reinstate function from the Deleted Items node.

What Happens When You Mark an Entry in Error??

When you Mark In Error…	The system records…
Entry moves to the Deleted Items node	Exact date and time
Entry remains visible (in Deleted Item Node) as erroneous	Reason provided (mandatory)
Entry is excluded from reports and data extracts	Original entry content
Entry stops contributing to active clinical data	Full audit trail

The Deleted Items node is only visible to users with the View Deleted Items access right.

Why It Matters

Correct the record

Removes incorrect data from active clinical decisions without erasing history.

Preserve history

Every correction is fully traceable — who acted, when, and why.

Prevent harm

Ensures wrong information cannot influence patient care or clinical decisions.

---

When to use Mark In Error

Use Mark In Error when an entry is fundamentally wrong and must be removed from active clinical data:

• Documentation entered in the wrong patient record
• Wrong SNOMED code or clinical finding selected
• Medication prescription entered in error — wrong drug, dose, or route
• Notes added to the wrong encounter or wrong date
• Wrong clinician listed as author of an entry
• Incorrect vaccination record — wrong part, dose, or history entry
• Incorrect referral or test order details

Correct errors immediately

Do not delay. An incorrect entry in active clinical data can influence clinical decisions and patient safety.

---

When NOT to use Mark In Error

Mark In Error is not a general editing tool. Do not use it for:

• Routine updates to patient information — use standard edit functions
• Adding new information to existing entries — use amendments or new entries
• Minor typos where clinical meaning is clear — use edit within the permitted timeframe
• Registration errors requiring IC number changes or record merges — use registration correction procedures
• Entries created by other organisations — use Request Mark In Error instead

---

Audit trail

Every Mark In Error action generates a permanent, unmodifiable audit record. It captures:

• User ID and role of the person who acted
• Exact timestamp
• Reason provided
• Original entry content
• Patient affected
• Node where the entry existed

This audit trail cannot be deleted or modified. It supports medicolegal defence, regulatory compliance, accountability, and quality improvement ISO 27789, in line with ISO 27001 9.4.5 / 12.4 logging and monitoring requirements DKICT-V5.

---

Best practices

Do

• Use the specific node (Medications, Observations, Code Journal) rather than New Journal for precision
• Provide clear, specific reasons — enough detail for any future reviewer to understand what happened
• Inform the responsible user if you marked their entry, where clinically relevant
• Escalate to supervisor when the error carries significant clinical risk
• For cross-organisation entries, use Request Mark In Error
• Nominate one person to manage incoming Mark in Error Request tasks
• Action all incoming requests within 4 days

Avoid

• Vague reasons: "Error", "Wrong", "Mistake", "Delete this"
• Blanket deletions from New Journal without checking scope
• Silently correcting entries that carry clinical risk without notifying a supervisor
• Leaving Mark in Error Request tasks unactioned beyond 4 days