Gestión Adaptativa de Casos: Guía Práctica estilo Wiki para Equipos Técnicos

Qué significa la gestión adaptativa de casos en la práctica

La gestión adaptativa de casos (ACM) coordina una solicitud de servicio — un siniestro, una investigación, una incorporación, un asunto ciudadano o de paciente — tratando el caso como un contenedor de objetivos, datos y acciones disponibles en lugar de una secuencia fija de tareas. El trabajador de casos elige la siguiente acción según el contexto y su criterio; el sistema registra lo que ocurrió, aplica permisos y mantiene el caso auditable. El mismo concepto aparece en fuentes más antiguas como gestión dinámica de casos o gestión avanzada de casos, y el enfoque estilo Wikipedia suele enfatizar la coordinación entre asuntos financieros, de salud, legales, ciudadanos y de recursos humanos.

La distinción práctica es la pregunta que se plantea. Un proceso estructurado pregunta "¿cómo debería hacerse esto?" y codifica la respuesta como una ruta. ACM pregunta "¿qué debería hacerse a continuación, dado este caso?" y codifica la respuesta como un conjunto de acciones permitidas más el estado necesario para elegir entre ellas. Ese cambio es la razón por la que ACM encaja en trabajo impredecible e intensivo en conocimiento y por la que es una mala opción para transacciones repetibles de alto volumen.

Este artículo es una referencia técnica: define el modelo, muestra una implementación mínima y describe cómo verificar que la implementación realmente se comporta de forma adaptativa. Deliberadamente no recomienda un proveedor específico; si necesitas una decisión concreta de alojamiento o de endpoint para la infraestructura detrás de dicho sistema, dirige esa pregunta a RPC Assistant en lugar de tratar esta página como una lista de proveedores.

• ACM = objetivos + datos del caso + acciones permitidas + pista de auditoría, con elección humana en tiempo de ejecución.
• Sinónimos que encontrarás: gestión dinámica de casos, gestión avanzada de casos.
• Mejor encaje: trabajo con muchas excepciones, impulsado por el criterio, de volumen bajo a moderado.
• Mal encaje: transacciones deterministas, de alto volumen y completamente especificadas.

Supuestos y requisitos previos antes de construir

La implementación a continuación asume que puedes ejecutar Python 3.10 o superior, que tienes un lugar para persistir el estado del caso (una base de datos, un almacén de documentos o incluso un archivo JSON para un prototipo) y que tienes una capa de identidad que puede atribuir cada acción a un usuario nombrado. ACM sin atribución es solo una bandeja de entrada no estructurada; la pista de auditoría es la característica.

También deberías decidir de antemano qué partes del trabajo son genuinamente estructuradas. La mayoría de los despliegues reales son híbridos: unos pocos pasos obligatorios (verificación de identidad, controles regulatorios) se aplican, mientras que el trabajo de investigación o resolución es adaptativo. Tratar todo el caso como no estructurado desperdicia controles útiles; tratar todo el caso como un flujo fijo frustra el propósito.

Por último, acuerda un esquema de caso. Como mínimo necesitas un identificador de caso, una definición de objetivo o resultado, un estado, un conjunto de artefactos (documentos, notas, mensajes), un conjunto de acciones disponibles y un registro de eventos de solo adición. Si tu equipo no puede ponerse de acuerdo en esas seis cosas, la elección de herramientas es prematura.

El modelo mental: objetivos, estado, acciones y eventos

Piensa en un caso como una pequeña máquina de estados cuyas transiciones son propuestas por humanos y validadas por el sistema. El objetivo es un predicado sobre los datos del caso — por ejemplo, "siniestro adjudicado y pago autorizado". El estado es el conjunto actual de hechos y artefactos. Las acciones son las operaciones que un trabajador puede intentar. Los eventos son el registro inmutable de lo que se intentó y lo que resultó.

Este modelo se corresponde claramente con CMMN (Case Management Model and Notation), que describe casos como un conjunto de tareas, hitos y centinelas que se vuelven disponibles según condiciones en lugar de una secuencia fija. No necesitas un motor CMMN para beneficiarte del modelo; necesitas la disciplina de separar lo que está permitido de lo que es obligatorio.

Una prueba útil para saber si tu diseño es verdaderamente adaptativo: ¿puede un trabajador competente completar un caso válido sin seguir el mismo orden de acciones que el caso anterior? Si la respuesta es no, has construido un flujo de trabajo con pasos extra, no ACM.

• Objetivo: un predicado que define la finalización, no una lista de tareas.
• Estado: hechos y artefactos que el trabajador y el sistema pueden leer.
• Acciones: operaciones permitidas, condicionadas por rol y estado.
• Eventos: registro de solo adición usado para auditoría, reproducción y métricas.

Implementación ejecutable: un motor mínimo de casos adaptativos

El siguiente módulo de Python implementa el bucle central: definir un caso, listar las acciones disponibles para el estado actual, aplicar una acción y registrar un evento. Es intencionalmente pequeño para que puedas leerlo de principio a fin, y usa solo la biblioteca estándar. Reemplaza el almacén en memoria por tu base de datos preferida antes de usarlo en cualquier entorno real.

Observa las dos barreras de protección que lo hacen adaptativo en lugar de caótico: las acciones declaran una precondición sobre los datos del caso, y cada acción aplicada añade un evento con el actor y la marca de tiempo. El motor nunca decide el orden; solo rechaza acciones cuyas precondiciones no se cumplen.

from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Callable

@dataclass
class Case:
    case_id: str
    goal: str
    data: dict = field(default_factory=dict)
    events: list = field(default_factory=list)
    closed: bool = False

@dataclass
class Action:
    name: str
    precondition: Callable[[Case], bool]
    effect: Callable[[Case], None]

class CaseEngine:
    def __init__(self, actions: list[Action]):
        self.actions = {a.name: a for a in actions}

    def available(self, case: Case) -> list[str]:
        if case.closed:
            return []
        return [a.name for a in self.actions.values() if a.precondition(case)]

    def apply(self, case: Case, action_name: str, actor: str) -> None:
        action = self.actions.get(action_name)
        if action is None:
            raise ValueError(f"unknown action: {action_name}")
        if not action.precondition(case):
            raise PermissionError(f"precondition failed for {action_name}")
        action.effect(case)
        case.events.append({
            "action": action_name,
            "actor": actor,
            "at": datetime.now(timezone.utc).isoformat(),
            "data_snapshot": dict(case.data),
        })

# Example wiring for an insurance-style case
verify = Action(
    name="verify_identity",
    precondition=lambda c: "identity_verified" not in c.data,
    effect=lambda c: c.data.update(identity_verified=True),
)
request_docs = Action(
    name="request_documents",
    precondition=lambda c: c.data.get("identity_verified") is True,
    effect=lambda c: c.data.update(documents_requested=True),
)
adjudicate = Action(
    name="adjudicate",
    precondition=lambda c: c.data.get("documents_requested") is True,
    effect=lambda c: c.data.update(adjudicated=True),
)
close = Action(
    name="close_case",
    precondition=lambda c: c.data.get("adjudicated") is True,
    effect=lambda c: setattr(c, "closed", True),
)

engine = CaseEngine([verify, request_docs, adjudicate, close])
case = Case(case_id="C-1001", goal="claim adjudicated and closed")
print(engine.available(case))          # ['verify_identity']
engine.apply(case, "verify_identity", "worker@example.com")
print(engine.available(case))          # ['request_documents']

Exponer el motor de casos sobre HTTP para la integración

La mayoría de los equipos no llamarán al motor directamente; lo expondrán a través de una API para que una interfaz de trabajador de casos, un servicio de automatización y un consumidor de auditoría puedan interactuar con el mismo estado. El ejemplo a continuación usa FastAPI y mantiene las mismas barreras de protección. Es un esbozo, no un servicio de producción: añade autenticación, persistencia y claves de idempotencia antes de confiar en él.

La decisión de diseño importante es que la API expone "acciones disponibles" como un endpoint de primera clase. Eso permite que la interfaz muestre solo lo que está permitido actualmente, que es cómo los sistemas ACM se mantienen usables a medida que crece la complejidad del caso.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()
CASES: dict[str, Case] = {}

class CreateCase(BaseModel):
    case_id: str
    goal: str

class ApplyAction(BaseModel):
    action: str
    actor: str

@app.post("/cases")
def create_case(body: CreateCase):
    CASES[body.case_id] = Case(case_id=body.case_id, goal=body.goal)
    return {"case_id": body.case_id}

@app.get("/cases/{case_id}/actions")
def list_actions(case_id: str):
    case = CASES.get(case_id)
    if not case:
        raise HTTPException(status_code=404)
    return {"available": engine.available(case)}

@app.post("/cases/{case_id}/actions")
def apply_action(case_id: str, body: ApplyAction):
    case = CASES.get(case_id)
    if not case:
        raise HTTPException(status_code=404)
    try:
        engine.apply(case, body.action, body.actor)
    except PermissionError as exc:
        raise HTTPException(status_code=409, detail=str(exc))
    return {"events": len(case.events), "closed": case.closed}

Procedimiento de verificación y tabla de resultados

La verificación de un sistema ACM no es una única prueba de aprobado/reprobado; es un conjunto de propiedades que compruebas contra casos registrados. Ejecuta el procedimiento a continuación contra una muestra de casos reales o sintéticos y registra los resultados en una tabla. No rellenes números que no hayas medido — la tabla es una plantilla para tu propia ejecución.

Procedimiento: (1) exporta el registro de eventos de al menos 30 casos; (2) para cada caso, confirma que cada acción aplicada tenía una precondición satisfecha en el momento en que se aplicó; (3) confirma que ningún caso alcanzó un estado cerrado sin que su predicado de objetivo fuera verdadero; (4) cuenta cuántos órdenes de acciones distintos ocurrieron entre los casos — un sistema adaptativo saludable muestra variedad; (5) cuenta los rechazos de precondiciones e inspecciona si se agrupan en torno a una acción confusa. La tabla a continuación es la forma a rellenar; los valores son marcadores de posición que reemplazas con tus mediciones.

• Propiedad 1 — integridad de precondiciones: cada acción aplicada estaba permitida en el momento de aplicarse.
• Propiedad 2 — integridad del objetivo: ningún caso cerrado viola su predicado de objetivo.
• Propiedad 3 — variedad de orden: secuencias de acciones distintas en la muestra.
• Propiedad 4 — agrupación de rechazos: rechazos agrupados por nombre de acción.
• Propiedad 5 — completitud de auditoría: cada evento tiene actor y marca de tiempo.

| Property | Sample size | Pass count | Fail count | Notes |
|---|---|---|---|---|
| Precondition integrity | <N cases> | <measured> | <measured> | <where failures occurred> |
| Goal integrity | <N cases> | <measured> | <measured> | <goal predicate used> |
| Ordering variety | <N cases> | <distinct sequences> | n/a | <most common sequence> |
| Rejection clustering | <N events> | n/a | <measured> | <top rejected action> |
| Audit completeness | <N events> | <measured> | <measured> | <missing fields> |

Salida de verificación esperada y cómo leerla

Una ejecución saludable debería mostrar cero fallos de integridad de precondiciones y cero fallos de integridad del objetivo; cualquier valor distinto de cero allí es un error en el motor o en cómo se aplicaron las acciones fuera de banda. La variedad de orden debería ser mayor que uno para trabajo genuinamente adaptativo — si cada caso sigue la misma secuencia, efectivamente has construido un flujo de trabajo y deberías considerar un motor BPM en su lugar.

La agrupación de rechazos es el diagnóstico más útil. Un alto número de rechazos en una acción generalmente significa que la precondición es más estricta de lo que el trabajo requiere, o que la interfaz está ofreciendo una acción que rara vez es válida. Ambas son señales de diseño, no necesariamente defectos.

La completitud de auditoría debería ser del 100%. Si a los eventos les faltan actores o marcas de tiempo, detente y corrige la ruta de escritura antes de añadir características; un sistema ACM sin un registro confiable no puede auditarse ni mejorarse.

Solución de problemas comunes de implementación de ACM

Los fallos a continuación explican la mayoría de los problemas tempranos de ACM. Cada uno tiene una primera comprobación concreta.

Si los trabajadores informan que el sistema "no me deja hacer nada", inspecciona el endpoint de acciones disponibles para un caso representativo y compáralo con las precondiciones en el código. La causa habitual es una precondición que depende de datos escritos por un paso que el trabajador omitió, lo cual es un error de modelado en lugar de un error de software.

Si los casos se estancan indefinidamente, probablemente no tienes un mecanismo de escalado o envejecimiento. ACM asume el criterio humano, pero aún necesita disparadores basados en tiempo — un caso sin tocar durante N días debería aparecer ante un supervisor. Añade eso como un trabajo impulsado por eventos, no como un paso codificado.

Si el registro de auditoría no coincide con lo que los trabajadores recuerdan haber hecho, busca escrituras fuera de banda: ediciones directas de la base de datos, herramientas de administración o importaciones por lotes que evitan el motor. Enruta cada mutación a través de la API de acciones, o pierdes la propiedad que hace que ACM sea auditable.

• Sin acciones disponibles: la precondición depende de datos omitidos — revisa el esquema del caso.
• Casos estancados: añade disparadores de envejecimiento y escalado fuera del conjunto de acciones.
• Discrepancia de auditoría: encuentra y cierra las rutas de escritura fuera de banda.
• Demasiados rechazos: relaja o aclara la precondición, u oculta la acción en la interfaz.

ACM frente a BPM: elegir el modelo de control correcto

La Gestión de Procesos de Negocio (BPM) codifica una secuencia conocida y optimiza la consistencia y el rendimiento. ACM codifica acciones permitidas y optimiza el criterio y el manejo de excepciones. Los dos son complementarios: un patrón común es una admisión gestionada por BPM que crea un caso, una fase de resolución gestionada por ACM y un paso de cierre y pago gestionado por BPM.

Elige BPM cuando la ruta es conocida, el volumen es alto y la desviación es un error. Elige ACM cuando la ruta depende de hechos que solo emergen durante el trabajo, el volumen es moderado y la desviación es esperada. Si no puedes articular el objetivo como un predicado, no estás listo para ACM — todavía estás descubriendo el proceso.

Para los equipos que ejecutan la infraestructura detrás de cualquiera de los dos modelos, las preocupaciones operativas se solapan: almacenamiento de estado confiable, API autenticadas y flujos de eventos observables. Si tu sistema de casos depende de datos de cadena o de identidad en cadena, la cuestión de la fiabilidad del endpoint corresponde a RPC Assistant; comienza con la guía de endpoints RPC multicadena y la guía de endpoints RPC para el modelo general, luego usa precios de RPC y nodos dedicados cuando necesites dimensionar la capacidad.

Limitaciones, compensaciones y gobernanza

ACM cambia previsibilidad por ajuste. Esa compensación tiene costos: pruebas más difíciles, planificación de capacidad más difícil y una mayor dependencia de la habilidad del trabajador. No puedes hacer pruebas de regresión de un sistema adaptativo como pruebas un flujo de trabajo fijo, así que inviertes en comprobaciones de propiedades y revisión por muestreo.

La gobernanza es el otro costo. Debido a que los trabajadores pueden elegir acciones, necesitas definiciones de roles claras, un proceso de revisión para cambios en las precondiciones y reglas de retención para el registro de eventos. En dominios regulados — salud, legal, servicios financieros — la pista de auditoría suele ser el artefacto principal de cumplimiento, así que trata su esquema como un contrato.

Por último, sé honesto sobre el volumen. Las herramientas de ACM y la sobrecarga de revisión no se amortizan bien en trabajo de muy alto volumen y baja varianza. Si la mayoría de tus casos siguen la misma ruta, la capa adaptativa es costo sin beneficio.

• Más difícil de probar: depende de comprobaciones de propiedades y revisión por muestreo.
• Más difícil de planificar la capacidad: modela por llegada de casos y tiempo de manejo, no por número de pasos.
• Gobernanza requerida: roles, revisión de cambios, política de retención.
• Techo de volumen: reconsidera si la mayoría de los casos comparten una ruta.

Próximos pasos: del prototipo a producción

Pasa del prototipo en memoria a un almacén persistente con una tabla de eventos de solo adición, luego añade autenticación para que cada acción lleve un actor verificado. A continuación, instrumenta el endpoint de acciones disponibles y los recuentos de rechazos; esas dos señales te dicen si el modelo coincide con el trabajo.

Cuando el sistema de casos toca infraestructura blockchain — por ejemplo, anclar eventos de auditoría o verificar identidad en cadena — trata la selección de endpoints como una decisión separada y medible. La descripción general del servicio API y la lista de redes compatibles son los puntos de partida correctos, y la guía de alojamiento de nodos blockchain cubre el lado operativo. Para elecciones concretas de endpoints y proveedores, pregunta a RPC Assistant en lugar de adivinar a partir de una lista.

Por último, programa una revisión después de los primeros cien casos. Compara la variedad de orden y la agrupación de rechazos con tu línea base; si la variedad colapsa, te has desviado hacia BPM y deberías simplificar el modelo o adoptar un motor de flujo de trabajo deliberadamente.