← Back to catalogue
Published

Clinical document and record entry

EM-HCP-08 · em-hcp-08

Keep clinical documents trustworthy as the legal record of care: who wrote what, when it was signed, and how it was corrected.

Enterprise profiles Enterprise subject EnterpriseHCP
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

2 bundles · 2 layers · 4 findings · 8 questions

Authorship and status Who wrote and signed the document.

Document life

Author, attester and status.

Authorship

Author, patient, encounter and signature.

  1. Who authored this document, for which patient and encounter?
  2. Who signed or attested this document, and when?

Status

Draft, final, amended or entered in error.

  1. Is this document a draft, final, amended or entered in error?
Corrections and sharing How the document changed and where it went.

Versions

Amendments, sharing and retention.

Amendments

Corrections with reasons and authors.

  1. Which amendments were made to this document, by whom and with what reason?
  2. Which version of this document was valid at a given date?

Sharing and retention

Shared versions, retention and structured content.

  1. With which providers or systems was this document shared, and which version?
  2. Which retention period applies to this document?
  3. Which structured entries are summarized in this document?

Classifiers Filled

Family
Enterprise profiles
Category
Enterprise subject
Entry kind
subject
Domain
EnterpriseHCP
Industry
Healthcare provider
Tags
EM-HCP-08W-INDsubjectClinicalDocumentDocumentSectionAttestationAmendmentDocumentStatus

What it is Filled

An authored clinical document or record entry, such as a note, a discharge summary or a report, with its author, attestation, status, amendments and medical record retention. Generic document management and terminology are separate contours.

Why it exists Filled

Keep clinical documents trustworthy as the legal record of care: who wrote what, when it was signed, and how it was corrected.

Distinguishing features Filled

  • Signed documents are amended, not edited.
  • Every document has an author and a status, while attestation is recorded when required for that status and may be absent for drafts or unsigned documents.
  • Shared versions remain traceable.
  • Generic document management is a separate contour.

What robots and AI may and may not do Filled

Must not

  • Sign or attest documents.
  • Edit signed documents.
  • Share documents outside approved exchange channels.

Only with a human decision

  • Only the responsible clinician signs or amends clinical documents.
  • Release of records to third parties follows an approved request process.

May

  • Summarize documents for authorized staff with references to the sources.
  • Flag unsigned documents past a deadline.
  • Draft documents for clinicians to review and sign.

Moral aspects Filled

  • Clinical documents are among the most sensitive personal records.
  • Drafts produced by tools can carry errors into the legal record if they are not reviewed.

Who is affected

  • Patients
  • Authoring clinicians
  • Receiving providers

Owners Filled

Steward

The head of medical records who answers for the integrity of the medical record.

Master systems

  • Electronic health record system
  • Clinical document repository
  • Health information exchange

Links to other meta-models Filled

neighbor

  • EM-KNW-01
  • EM-HCP-03
  • EM-HCP-05
  • EM-HCP-07
  • EM-XCT-05
  • EM-XCT-04

references

  • WM-REC-001 - conceptual-candidate
  • WM-REC-002 - conceptual-candidate

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A clinical document has an identifier unique within the repository and a version identifier.
  • It references one patient record and usually one encounter.

Direct properties not applicable Not applicable

Not applicable

Enterprise record contour: physical properties belong to referenced world models.

Recognition required Filled

  • Records show a document type, author, status and version, with attestation details when present and any unmet attestation requirement visible.
  • A clinical document must be distinguished from a generic file, a form template and a message.

Capabilities and actions required Filled

  • The contour supports legal record keeping, document exchange and version history.

Hazards and failure modes required Filled

  • Silent edits can hide errors and harm patients.
  • Sharing the wrong version can mislead other providers.

Standards and interfaces optional Filled

  • HL7 International publishes the FHIR Composition and DocumentReference resources and the CDA standard.
  • Integrating the Healthcare Enterprise publishes the XDS profile for cross-enterprise document sharing.

Context of use required Filled

  • The contour is used in all care settings that keep a medical record.
  • Medical record retention follows applicable national and subnational law and other governing obligations, including any applicable preservation holds.

Sources Filled

  1. HL7 FHIR: Composition and DocumentReference resources
  2. HL7 CDA and openEHR compositions
  3. IHE XDS: cross-enterprise document sharing
  4. HL7 FHIR R4 Composition resource - Checked live (HTTP 200) on 2026-10-21.
  5. HL7 FHIR R4 DocumentReference resource - Checked live (HTTP 200) on 2026-10-21.
  6. IHE ITI Technical Framework: Cross-Enterprise Document Sharing (XDS.b) - Checked live (HTTP 200) on 2026-10-21.

Open questions

  • How is an amendment recorded so that the original remains readable?
  • When does a document become part of the legal medical record?
  • How are structured entries and narrative text kept consistent?
  • Settle the boundary and the reuse, extend or new decision against the current specifications.
  • Confirm the semantic crosswalk, rights and source mastership.
  • Choose immutable references and run fixture checks before claiming publication readiness.

Machine files

Card as JSON Source Card backlog vercy.card/1

Provenance

enterprise research programme · published-partial

Built from: enterprise/models/em-hcp-08/brief.json, ver-cy/world-models/card-supplements/em-hcp-08.json