Propiedades

Propiedad Tipo Definición
Administrativo
Identificador del registro string
Un identificador único para este registro (por ejemplo, un ULID, UUID o ID asignado por el programa). Su alcance se limita al espacio de nombres del registro; no es necesariamente único a nivel global.
Identificadores concept:Identifier
Identificadores que porta esta entidad, como números de identidad nacional, ID de programa o identificadores acreditados por un documento de identidad.
Identificador externo string
Identificadores asignados por sistemas externos (CRM, gestión de casos, etc.). Se permiten múltiples valores porque un registro puede tener identificadores de varios sistemas.
Versión del esquema uri
Identifica la versión del esquema de registro de consentimiento de PublicSchema (u otro) al que se ajusta esta instancia. Permite las herramientas de migración hacia versiones posteriores. Normalmente es un URI desreferenciable, por ejemplo 'https://publicschema.org/ConsentRecord/v1'.
Conforme a uri
URIs de las normas o especificaciones con las que este registro es conforme (ISO/IEC TS 27560, Kantara Consent Receipt, W3C DPV, etc.). Puramente declarativo; no se realiza ninguna validación contra las normas citadas a nivel de esquema.
Creado el datetime
Marca de tiempo generada por el sistema que indica cuándo se almacenó este registro. Es la marca de tiempo de digitalización, no la fecha de otorgamiento del consentimiento. Distinta de 'signed_date' (el día en que la persona interesada indicó su consentimiento) y de 'effective_date' (cuando el registro entra en vigor). Para los flujos de trabajo en papel, las tres marcas de tiempo pueden diferir.
Referencia de sesión de recopilación string
Clave de correlación opaca para los registros producidos en la misma sesión de registro. Un concepto 'CollectionSession' está planificado en ADR-013 y lo formalizará; en la versión 1, los adoptantes utilizan un identificador de sesión de forma libre (por ejemplo, un identificador de visita de campo).
Persona interesada concept:Party incluye Person, Group, Household, Family, Farm
La persona física (o en ocasiones el grupo) cuyos datos personales se tratan bajo este registro. Party es el supertipo abstracto que abarca Person y Group. Farm está excluido: las explotaciones agrícolas no son personas físicas ni beneficiarias legales bajo ninguna ley de protección de datos. Cuando 'data_subject' es un Group, 'delegation_type' no debe ser 'self'.
Responsables del tratamiento concept:Organization
Organizaciones que determinan los fines y los medios del tratamiento. La cardinalidad múltiple cubre la corresponsabilidad (dos o más organizaciones conjuntamente responsables en virtud del Art. 26 del RGPD o disposiciones nacionales equivalentes); el caso normativo es un único responsable del tratamiento. Véase 'recipient_role' para distinguir los encargados del tratamiento de los responsables entre los destinatarios.
Destinatarios concept:Organization
Organizaciones que reciben los datos o sus derivados. Incluye encargados del tratamiento, corresponsables del tratamiento y responsables del tratamiento independientes. Véase la propiedad paralela 'recipient_role' para conocer el rol de cada destinatario.
Rol del destinatario string (recipient-role)
El rol que desempeña cada destinatario: encargado del tratamiento, corresponsable del tratamiento, responsable independiente del tratamiento o subencargado del tratamiento. Limitación conocida: la versión 1 usa alineación posicional con 'recipients' (el N-ésimo valor de recipient_role corresponde al N-ésimo destinatario). Un futuro ADR reificará los roles por enlace. Los adoptantes que no puedan garantizar la alineación posicional deben usar un único destinatario y un único rol por registro, o representar la relación externamente.
Categorías de destinatarios permitidos string (organization-type)
Categorías de organizaciones autorizadas a recibir los datos, tal como se describen a la persona interesada en el aviso. Complementa 'recipients', que nombra organizaciones específicas. Se usa cuando las organizaciones destinatarias específicas no están preidentificadas en el momento del consentimiento.
Indicado por concept:Agent incluye Person, Organization, SoftwareAgent
El agente (generalmente una Person, a veces un SoftwareAgent) que indicó el acto de consentimiento. Para el consentimiento propio, la misma Person que 'data_subject'. Para el consentimiento delegado, un tutor legal, padre o representante. Véase 'delegation_type' para describir la base de la delegación.
Tipo de delegación string (delegation-type)
La base bajo la cual 'indicated_by' actúa en nombre de 'data_subject'. El valor 'self' indica que no hay delegación: la persona interesada indicó su propio consentimiento. Todos los demás valores indican que un tercero actuó en nombre de la persona interesada.
Atestiguado por concept:Person
Personas que fueron testigos de la indicación de consentimiento de la persona interesada. Crítico en el campo para el consentimiento verbal ('collection_medium = verbal') y para la biometría como firma ('consent_expression = opt-in-biometric') y las firmas presenciadas ('consent_expression = opt-in-witnessed'); los adoptantes deben completar este campo incluso cuando la interfaz de entrada de datos no lo requiera.
Finalidades del tratamiento uri
Los valores son URI W3C DPV, subclases normativas de `dpv:Purpose` (por ejemplo, `dpv:ServiceProvision`, `dpv:ResearchAndDevelopment`). Cada URI identifica una finalidad para la cual se procesan datos personales en este registro. Consulte `docs/dpv-vocabulary-reference.md` para una lista de inicio seleccionada.
Categorías de datos personales uri
Los valores son URI W3C DPV, subclases normativas de `dpv:PersonalData` (del núcleo DPV; la extensión DPV-PD define taxones más específicos). No confundir con el método de captura biométrica, que es `consent_expression = opt-in-biometric` en este registro. Las categorías de datos biométricos son valores de esta propiedad (por ejemplo, un URI para huella dactilar, imagen facial).
Operaciones de tratamiento uri
Los valores son URI W3C DPV, subclases normativas de `dpv:Processing` (por ejemplo, `dpv:Collect`, `dpv:Store`, `dpv:Share`). Describe las operaciones para las que se otorga el consentimiento. Referencia: RGPD Art 4(2) para la definición de 'tratamiento'.
Base de categoría especial string (special-category-basis)
Cuando `personal_data_categories` incluye una categoría especial (RGPD Art 9 / `dpv:SpecialCategoryPersonalData`), esta propiedad identifica la base del Art 9(2) que autoriza el tratamiento. Obligatorio cuando hay datos Art 9 en alcance; omitido en caso contrario. Campo crítico: completar incluso si su interfaz no lo exige.
Acuerdo de corresponsabilidad string
Referencia al acuerdo de corresponsabilidad entre las partes listadas en `controllers` (RGPD Art 26). Típicamente un URI hacia un acuerdo publicado; un identificador local es aceptable si no aplica un URI. Completar cuando la cardinalidad de `controllers` es mayor que uno.
Aviso de privacidad concept:PrivacyNotice
El registro PrivacyNotice que fue presentado a la persona interesada en el momento del consentimiento. Vincula el registro a una versión específica del aviso.
Versión del aviso string
Instantánea desnormalizada de la `version` del PrivacyNotice en el momento del consentimiento. Fijada por diseño: si el PrivacyNotice es corregido o reversionado posteriormente, este valor NO DEBE actualizarse. Permite demostrar qué texto del aviso vio realmente la persona interesada (RGPD Art 7(1), demostrabilidad).
Idioma de presentación del aviso string (language)
El código de idioma ISO 639-3 en que el aviso fue presentado a la persona interesada en el momento del consentimiento. Campo crítico: completar incluso si la interfaz no lo exige. Cuando el aviso está disponible en varios idiomas (véase PrivacyNotice `available_languages`), este campo registra cuál vio realmente la persona interesada. Para el consentimiento verbal presenciado, registra el idioma de la entrega verbal.
Fecha de vigencia date
La fecha en que este registro o aviso se vuelve operativo. En un ConsentRecord, puede ser posterior a signed_date (el día en que la persona afectada indicó su consentimiento) y a created_at (la marca de tiempo de digitalización); en flujos en papel, signed_date es el día de la firma del formulario en papel y effective_date es normalmente el mismo día, pero puede retrasarse según la lógica del programa. En un PrivacyNotice, es la fecha a partir de la cual se aplica esta versión del aviso; los registros recogidos antes de esa fecha remiten a la versión anterior mediante supersedes_ref.
Fecha de firma date
El día en que la persona afectada indicó su consentimiento. En flujos en papel, el día en que se firmó el formulario; para consentimiento verbal con testigo, el día de la indicación verbal; en digital, el día del clic de aceptación. NO debe confundirse con created_at (la marca de tiempo de digitalización, que puede ser días o semanas posterior en programas con soporte papel) ni con effective_date (cuando el registro se vuelve operativo). Crítico para la recolección: registrar aunque la interfaz solo capture created_at.
Fecha de expiración date La fecha en que este registro o documento expira o deja de ser válido.
Jurisdicción string (country)
Código de país ISO 3166-1 alpha-2 de la jurisdicción cuya ley de protección de datos rige este registro. Cardinalidad simple: los registros multi-jurisdiccionales son el caso excepcional; un ADR posterior podrá ampliar la cardinalidad si los adoptantes lo necesitan. En caso de responsabilidad conjunta, corresponde a la jurisdicción de establecimiento principal del responsable principal.
Medio de recopilación string (collection-medium)
El medio a través del cual se recopiló el consentimiento: papel, electrónico, verbal o mixto. El papel es el medio dominante en programas humanitarios y de protección social en zonas rurales; los sistemas electrónicos que ignoran los flujos en papel excluyen la práctica real. Crítico para la recolección: registrar aunque el sistema asuma por defecto el medio electrónico.
Referencia a evidencias string
Referencias a los artefactos de evidencia que respaldan este registro. Los valores son típicamente URIs (por ejemplo, una URL firmada de almacenamiento de objetos), pero un identificador local es aceptable cuando no aplica una URI. Los tipos de artefactos incluyen: escaneos PDF de formularios en papel firmados, fotografías de registros de consentimiento, grabaciones de audio de consentimientos verbales con testigo, y documentos digitales firmados. Se recomienda al menos un evidence_ref cuando collection_medium es {paper, verbal, mixed}. Crítico para la recolección: registrar aunque la URI del artefacto solo esté disponible tras la carga.
Verificado por concept:Person
Persona que verificó el registro de consentimiento (por ejemplo, un trabajador social que revisa un formulario en papel escaneado, o un auditor que confirma una muestra de registros). Distinto de witnessed_by (quien observó el acto de consentimiento) y de indicated_by (quien expresó el consentimiento). Opcional pero valioso para flujos de trabajo auditables.
Fecha de verificación date
Fecha del acto de verificación realizado por verified_by. Típicamente posterior a signed_date.
Estado string (consent-status)
El estado actual del ciclo de vida del registro: solicitado, otorgado, renovado, rechazado, retirado, revocado, expirado, invalidado o desconocido. Las transiciones siguen la máquina de estados documentada en docs/consent-lifecycle.md. given activa la inmutabilidad de los campos de condiciones (data_subject, controllers, recipients, purposes, etc.); consulte la anotación immutable_after_status en cada propiedad correspondiente.
Canal de retiro string (withdrawal-channel)
El canal por el que la persona afectada retiró su consentimiento: web, móvil, api, papel, verbal, en-persona-oficina, agente-comunitario u otro. Se registra cuando el estado pasa a withdrawn. Crítico para la recolección: los adoptantes deben registrar el canal incluso cuando el retiro llega por una vía no digital.
URI de retiro uri
URI expuesta a la persona afectada para el retiro autónomo de su consentimiento. Requerida por el Art. 7(3) del RGPD ('debe ser tan fácil retirar el consentimiento como otorgarlo'). Se rellena en el ConsentRecord cuando el responsable del tratamiento ofrece un punto de acceso de autoservicio.
Motivo de retiro string
Motivo de retiro en texto libre, si la persona afectada lo comunica. La persona afectada no está obligada a dar un motivo; este campo existe para cuando lo hace, con fines de mejora del servicio por parte del responsable del tratamiento.
Motivo de rechazo string
Motivo de rechazo en texto libre cuando la persona afectada declinó consentir (estado = refused). Distinto de withdrawal_reason, que se aplica después de que el consentimiento fue otorgado inicialmente y luego retirado.
Plazo de conservación (días) integer
Duración de almacenamiento planificada para los datos personales cubiertos por este registro, expresada en días. Dirige la lógica de retención en sistemas posteriores. Cero significa: no conservar tras el procesamiento. Nulo (no rellenado) significa: la duración se describe en prosa en el campo retention_description de la PrivacyNotice en lugar de codificarse.

Evidencia

Presente en 4 de 6 sistemas de prestación relevados.

Consent record structure converges across OpenSPP (spp.consent.record), OpenIMIS insuree consent records, openCRVS permission tracking, GovStack Consent Building Block, W3C DPV, ISO/IEC TS 27560, and Kantara Consent Receipt v1.1. Variation is mainly in scope (single vs joint controller, digital vs paper workflow, consent-only vs full legal-basis coverage). This concept takes the broader scope; narrower profiles are available via external_equivalents on specific properties.

Norma Equivalente Correspondencia
W3C DPV v2 Consent Record exact
W3C Data Privacy Vocabulary 2.0 defines dpv:ConsentRecord as a record of consent and provides predicates (hasDataSubject, hasDataController, hasPurpose, etc.) that align with our properties. Our ConsentRecord is the direct equivalent; ours adds field-workflow fields (signed_date, witnessed_by, collection_medium) that DPV does not name.
FHIR R4 Consent close
FHIR R4 Consent is the canonical health-sector consent record. Scope is close but narrower: FHIR Consent is health-centric, single-controller, and does not model receipt-as-record-type. Our ConsentRecord generalises across domains; fields verified_by, verified_date map to FHIR verification, verificationDate.
FHIR R5 Consent close
FHIR R5 revises Consent and introduces the separate Permission resource for controller-side authorization. Mapping is primarily to R5 Consent; our evidence_ref maps to sourceAttachment and verified_by / verified_date map to verification.verifiedWith / verificationDate.

Referenciado por este concepto