FHIR © HL7.org  |  Server Home  |  XIG Home  |  Server Source  |  FHIR  

FHIR IG Statistics: Requirements/EHRSFMR2-TI.1.5

Packagehl7.ehrs.uv.ehrsfmr2
TypeRequirements
IdEHRSFMR2-TI.1.5
FHIR VersionR5
Sourcehttp://hl7.org/ehrs/uv/ehrsfmr2/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2-TI.1.5.html
URLhttp://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-TI.1.5
Version2.1.1-ballot
Statusactive
Date2025-05-13T15:11:00+00:00
NameTI_1_5_Non_Repudiation
TitleTI.1.5 Non-Repudiation (Function)
Realmuv
Authorityhl7
DescriptionLimit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.
PurposeAn EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include: - Digital signature, which serves as a unique identifier for an individual (much like a written signature); - Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received); - Timestamp, which proves that a document existed at a certain date and time; - The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).

Resources that use this resource

No resources found


Resources that this resource uses

No resources found


Narrative

Note: links and images are rebased to the (stated) source

Statement N:

Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.

Description I:

An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:

  • Digital signature, which serves as a unique identifier for an individual (much like a written signature);
  • Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received);
  • Timestamp, which proves that a document existed at a certain date and time;
  • The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).
Actors:
ehr
Criteria N:
TI.1.5#01 dependent SHALL

The system SHALL capture the identity of the entity taking the action according to scope of practice, organizational policy, and/or jurisdictional law.

TI.1.5#02 dependent SHALL

The system SHALL capture time stamp of the initial entry, modification and exchange of data according to scope of practice, organizational policy, and/or jurisdictional law.

TI.1.5#03 dependent SHALL

The system SHALL conform to function TI.2 (Audit) to prevent repudiation of data origination, transmission and receipt according to scope of practice, organizational policy, and/or jurisdictional law.

TI.1.5#04 dependent SHOULD

The system SHOULD conform to function RI.1.1.4 (Attest Record Entry Content) to ensure integrity of data and data exchange and thus prevent repudiation of data origination, transmission or receipt according to scope of practice, organizational policy, and/or jurisdictional law.


Source

{
  "resourceType": "Requirements",
  "id": "EHRSFMR2-TI.1.5",
  "meta": {
    "profile": [
      "http://hl7.org/ehrs/uv/ehrsfmr2/StructureDefinition/FMFunction"
    ]
  },
  "text": {
    "status": "extensions",
    "div": "<!-- snip (see above) -->"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
      "valueCode": "ehr"
    }
  ],
  "url": "http://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-TI.1.5",
  "version": "2.1.1-ballot",
  "name": "TI_1_5_Non_Repudiation",
  "title": "TI.1.5 Non-Repudiation (Function)",
  "status": "active",
  "date": "2025-05-13T15:11:00+00:00",
  "publisher": "HL7 International / Electronic Health Records",
  "contact": [
    {
      "telecom": [
        {
          "system": "url",
          "value": "http://www.hl7.org/Special/committees/ehr"
        }
      ]
    }
  ],
  "description": "Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.",
  "jurisdiction": [
    {
      "coding": [
        {
          "system": "http://unstats.un.org/unsd/methods/m49/m49.htm",
          "code": "001",
          "display": "World"
        }
      ]
    }
  ],
  "purpose": "An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:\n- Digital signature, which serves as a unique identifier for an individual (much like a written signature);\n- Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received);\n- Timestamp, which proves that a document existed at a certain date and time;\n- The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).",
  "statement": [
    {
      "extension": [
        {
          "url": "http://hl7.org/ehrs/uv/ehrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean": true
        }
      ],
      "key": "EHRSFMR2-TI.1.5-01",
      "label": "TI.1.5#01",
      "conformance": [
        "SHALL"
      ],
      "conditionality": false,
      "requirement": "The system SHALL capture the identity of the entity taking the action according to scope of practice, organizational policy, and/or jurisdictional law.",
      "derivedFrom": "EHR-S_FM_R1.1 IN.1.5#1"
    },
    {
      "extension": [
        {
          "url": "http://hl7.org/ehrs/uv/ehrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean": true
        }
      ],
      "key": "EHRSFMR2-TI.1.5-02",
      "label": "TI.1.5#02",
      "conformance": [
        "SHALL"
      ],
      "conditionality": false,
      "requirement": "The system SHALL capture time stamp of the initial entry, modification and exchange of data according to scope of practice, organizational policy, and/or jurisdictional law.",
      "derivedFrom": "EHR-S_FM_R1.1 IN.1.5#2"
    },
    {
      "extension": [
        {
          "url": "http://hl7.org/ehrs/uv/ehrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean": true
        }
      ],
      "key": "EHRSFMR2-TI.1.5-03",
      "label": "TI.1.5#03",
      "conformance": [
        "SHALL"
      ],
      "conditionality": false,
      "requirement": "The system SHALL conform to function [TI.2](Requirements-EHRSFMR2-TI.2.html) (Audit) to prevent repudiation of data origination, transmission and receipt according to scope of practice, organizational policy, and/or jurisdictional law.",
      "derivedFrom": "EHR-S_FM_R1.1 IN.1.5#3"
    },
    {
      "extension": [
        {
          "url": "http://hl7.org/ehrs/uv/ehrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean": true
        }
      ],
      "key": "EHRSFMR2-TI.1.5-04",
      "label": "TI.1.5#04",
      "conformance": [
        "SHOULD"
      ],
      "conditionality": false,
      "requirement": "The system SHOULD conform to function [RI.1.1.4](Requirements-EHRSFMR2-RI.1.1.4.html) (Attest Record Entry Content) to ensure integrity of data and data exchange and thus prevent repudiation of data origination, transmission or receipt according to scope of practice, organizational policy, and/or jurisdictional law.",
      "derivedFrom": "EHR-S_FM_R1.1 IN.1.5#4"
    }
  ]
}