Implantación y operación de sistemas

Un sistema de información tiene un ciclo de vida (ライフサイクル) que va de la planificación y la adquisición (企画・調達) a la implantación, la operación, la evaluación y la siguiente renovación, y es importante reflejar en el plan del siguiente sistema las evaluaciones realizadas durante la operación. La implantación no es un hecho único, y el término no se refiere solo a la vida útil (耐用年数) del hardware. La opción que ignora los resultados de la evaluación también contradice el concepto de ciclo de vida.

Una RFP (Request for Proposal, 提案依頼書) es un documento en el que la institución sanitaria expone sus requisitos y condiciones de adquisición y pide a los proveedores (ベンダ) que presenten propuestas. El documento que pide información sobre productos y tecnologías es una RFI (solicitud de información, 情報提供依頼書), que se usa en la etapa anterior a la fijación de los requisitos. Una cotización solo de precio o un documento de diseño detallado posterior al contrato no son una RFP.

En la adquisición (調達), primero se aclaran los requisitos (調達要件), luego se estudia el método de adquisición y se crean los criterios de evaluación de proveedores (ベンダ評価基準), después se prepara y emite la RFP y, por último, se evalúan las propuestas para seleccionar al proveedor y firmar el contrato. Un orden en el que la RFP preceda a la aclaración de requisitos, o en el que el contrato vaya primero, es imposible. El punto clave es que los criterios de evaluación se preparan antes de emitir la RFP.

Una especificación de requisitos (要求仕様書) es un documento en el que la institución sanitaria aclara los requisitos que exige al sistema y se los transmite a los proveedores para la adquisición. Describe los requisitos básicos, los requisitos técnicos de hardware y software, los requisitos de conexión entre sistemas, etc. Un informe de finalización de la entrega, el código fuente y los procedimientos de respuesta a fallos no son especificaciones de requisitos.

Crear los criterios de evaluación (評価基準) antes de emitir la RFP permite comparar las propuestas de forma justa y objetiva con la misma vara de medir. Crear los criterios después de ver las propuestas favorece una evaluación arbitraria. Seleccionar solo por el precio ignora la funcionalidad y la capacidad de mantenimiento, y dar información adicional a un proveedor concreto socava la equidad, por lo que esas prácticas son inadecuadas.

Un arrendamiento financiero (leasing, リース) es una modalidad en la que se toma prestado a largo plazo un equipo comprado por una empresa de leasing y, por regla general, no puede cancelarse antes de su vencimiento (中途解約). Un alquiler (レンタル) es para uso a corto plazo y puede cancelarse antes de su vencimiento, lo que lo distingue del leasing. En un leasing es la empresa de leasing, y no la institución sanitaria, la que compra el equipo y lo registra como activo. El equipo comprado pasa a ser un activo de la institución, pero no puede evitar el riesgo de obsolescencia (陳腐化) por el avance tecnológico.

La externalización (業務委託) es un contrato en el que el contratista realiza el trabajo bajo su propia responsabilidad y dirección; la institución sanitaria que hace el encargo no puede supervisar directamente a los trabajadores del contratista. En la cesión de personal temporal (人材派遣), la institución sanitaria usuaria dirige a los trabajadores cedidos. Dónde reside el derecho de dirección (指揮命令権) es la diferencia esencial entre ambos; no se trata solo de una diferencia de nombre.

El mantenimiento de software (ソフトウェア保守) abarca la corrección de los defectos (bugs, 不具合) descubiertos después de la puesta en marcha y la aplicación de correcciones al programa. Sustituir o reparar piezas del servidor es mantenimiento de hardware (ハードウェア保守). Tender cables de LAN y trasladar terminales son trabajos de construcción e instalación, fuera del alcance de un contrato de mantenimiento de software.

Para conectar varios sistemas, como la historia clínica electrónica y los sistemas departamentales, la especificación de requisitos debe indicar claramente los sistemas que se van a conectar, los tipos de información que se van a intercambiar y el método de conexión (接続方式), incluido el uso de estándares (標準規格), y aclarar el alcance de las responsabilidades. Decidirlo después de la puesta en marcha, dejarlo en manos de los proveedores u omitirlo cuando los productos son del mismo proveedor provoca fallos de conexión y responsabilidades poco claras.

La implantación de un sistema de información hospitalaria forma parte de una estrategia de TI (情報化戦略) basada en la estrategia de gestión (経営戦略); la participación de la dirección y la construcción de consenso son esenciales, y el director de información en el ámbito sanitario (CIO sanitario, 医療CIO) lidera la planificación y el impulso de la estrategia. Decidir solo dentro del departamento de TI carece de consenso. Los propósitos se han diversificado e incluyen la mejora de la calidad de la atención y la cooperación, y la estrategia debe evaluarse y revisarse repetidamente.

Los maestros (マスター) de medicamentos, nombres de enfermedades, elementos de análisis, usuarios, etc., dependen en gran medida de la situación real de la institución, como los medicamentos que adopta y sus normas de operación, por lo que la institución sanitaria debe participar activamente en su preparación. No pueden dejarse en manos del proveedor, y el sistema no funcionará correctamente si no están listos antes de la puesta en marcha. Los maestros también requieren una gestión continua después de la puesta en marcha, por ejemplo para seguir las revisiones de los precios de los medicamentos (薬価改定).

La fase de implantación avanza por el detalle de la operación y las especificaciones (運用・仕様の詳細化), el desarrollo, la configuración y la construcción del sistema, la creación de datos maestros (マスター作成), las pruebas del sistema, la migración de datos y la formación de los usuarios; antes de la puesta en marcha se realiza una prueba operativa (ensayo general, 運用テスト・リハーサル), y el servicio comienza (サービスイン) después de la aceptación (検収). Los órdenes en los que la aceptación o el ensayo general preceden al detalle de las especificaciones o a la creación de maestros no se sostienen.

En la migración de datos (データ移行) es importante decidir qué partes de la información básica del paciente y de los datos clínicos se van a migrar, estudiar el método de migración, llevarla a cabo y luego verificar que los datos se traspasaron correctamente. Para mantener la continuidad de la atención, debe planificarse y realizarse antes de la puesta en marcha; omitir la verificación o desechar los datos clínicos sin traspasarlos es inadecuado.

La aceptación (検収) es el acto por el cual la institución sanitaria que hizo el encargo confirma que el sistema entregado funciona según lo especificado en los requisitos y lo acepta; la entrega se completa con la aceptación. Las pruebas unitarias (単体テスト) internas del proveedor forman parte de las pruebas del sistema, la formación sobre el manejo es formación de usuarios, y el análisis de las causas de fallos es una actividad de la fase de operación; nada de ello es la aceptación.

La prueba operativa (ensayo general, 運用テスト・リハーサル) usa el sistema como en producción, siguiendo el flujo de trabajo real desde la recepción hasta las consultas, los análisis y el pago, para detectar los problemas operativos antes de la puesta en marcha. La revisión del código fuente es una prueba del lado del desarrollador, la estimación del esfuerzo pertenece a la etapa de adquisición y contrato, y medir la capacidad del aire acondicionado es una cuestión de instalaciones, no el propósito de la prueba operativa.

Los grupos de trabajo (ワーキンググループ) reúnen a representantes de primera línea —médicos, enfermeras, técnicos, personal administrativo— para detallar la operación y las especificaciones de cada departamento, conciliar las peticiones y avanzar en la construcción de consenso (合意形成) dentro del hospital. Su propósito no es ocultar el precio del contrato, ni sustituir la toma de decisiones de la dirección (como los comités), ni servir como medida de reducción de personal.

En el lado del proveedor se forma una estructura de proyecto en torno a un jefe de proyecto (プロジェクトマネージャ), con personal para el diseño, el desarrollo y el apoyo a la implantación, que se coordina con la estructura correspondiente de la institución sanitaria. Un solo representante comercial no se encarga de todas las fases. La estructura se presenta a la institución en las propuestas y documentos similares, y asignar al personal también es necesario para que los puntos de contacto de coordinación sean claros.

En las implantaciones en las que participan varios proveedores, como la historia clínica electrónica y los sistemas departamentales, es importante establecer de antemano mecanismos —como reuniones de coordinación— para la coordinación entre las organizaciones dentro del hospital, entre el hospital y los proveedores, y entre los proveedores (ベンダ間の調整). Las respuestas improvisadas una vez surgidos los problemas y negarse a compartir las especificaciones de conexión provocan fallos de conexión. Los resultados de la coordinación deben registrarse y compartirse.

Inmediatamente después del inicio del servicio (サービスイン), las preguntas sobre el manejo y los problemas tienden a concentrarse, por lo que el personal del proveedor y del departamento de TI permanece presente en el lugar y responde de inmediato (apoyo en la puesta en marcha, 運用後立ち合い). Negarse a atender los fallos, suspender las cuentas justo después de la puesta en marcha y borrar de inmediato los datos del sistema antiguo socavarían la continuidad de la atención y la conservación de los datos, y son inadecuados.

Los propósitos de implantar un sistema de información hospitalaria se han diversificado más allá de la eficiencia administrativa y las reclamaciones al seguro, e incluyen la mejora de la calidad y la seguridad de la atención (医療の質・安全), su uso en la gestión y el apoyo a la cooperación regional (地域連携). Aclarar el propósito es una condición previa para redactar la especificación de requisitos y para la evaluación posterior a la implantación; implantar sin propósitos definidos o reducir el propósito a un solo aspecto no es adecuado.

Las normas de operación se organizan en 3 capas: la política (ポリシー), que expone los principios básicos; el estándar (スタンダード), es decir, el reglamento de gestión de la operación que la concreta; y los procedimientos (プロシージャ), que definen los pasos del trabajo diario. Los procedimientos están al nivel de manual y los estándares al nivel de reglamento, no de política básica. "Manifiesto" no es un término de esta estructura de 3 capas.

El reglamento de gestión de la operación (運用管理規程) define los objetos y la estructura de la gestión, las responsabilidades de los administradores, los responsables y los usuarios, el uso de servidores, terminales y redes, el manejo y almacenamiento de datos, la educación y la formación, las medidas de seguridad para el trabajo externalizado (業務委託), las disposiciones sancionadoras, etc. Una lista de los diagnósticos de cada paciente es contenido de los registros clínicos y no corresponde a un reglamento que establece normas de operación.

En la gestión de usuarios (ユーザ管理), el alta y la suspensión de cuentas deben vincularse con la información de personal, y la regla básica es suspender con prontitud las cuentas de las personas que dejan la institución. Compartir ID hace que carezca de sentido el registro de quién hizo qué (la pista de auditoría, 監査証跡), y dejar activos los ID de quienes se han ido o pegar las contraseñas favorece el acceso no autorizado; todo ello es inadecuado.

El principio de segregación (セグリゲーションの原則) separa la autoridad y las funciones en lugar de concentrarlas en 1 persona —por ejemplo, haciendo que el registro y la aprobación los realicen personas distintas— para que los controles mutuos eviten el fraude y los errores. Dar a todos privilegios de administrador y unificar las contraseñas va en contra de una gestión segura. Pintar los terminales de colores no tiene nada que ver con la segregación de funciones.

Eliminar una entrada del maestro hace imposible mostrar correctamente los datos de transacciones anteriores (トランザクションデータ) que la referencian, como los historiales de prescripción. Para preservar la coherencia (整合性) entre el maestro y los datos de transacciones, la entrada se desactiva (se suspende su uso, 無効化) en lugar de eliminarse. Reescribir el nombre cambia el significado de los registros anteriores, y no hacer nada provoca órdenes erróneas.

Ante un fallo del sistema, se evalúa el alcance del impacto (影響範囲), se avisa con prontitud a los departamentos usuarios y se pasa a una operación alternativa predefinida (代替運用), como los procedimientos en papel, para que la atención pueda continuar. Tras la recuperación, los registros hechos durante la operación alternativa se introducen de forma retroactiva (遡及入力). Suspender toda la atención socava la continuidad de la atención, y realizar los trabajos de recuperación sin avisar deja a la primera línea sin capacidad de juzgar la situación y causa confusión.

El IT-BCP, como parte de la gestión de la continuidad del negocio (事業継続マネジメント) en un centro sanitario, es un plan para continuar y reanudar rápidamente las operaciones críticas incluso durante desastres y fallos, mientras que la recuperación ante desastres (ディザスターリカバリー) se refiere a restaurar y reconstruir los sistemas de información dañados. Es importante no solo elaborar el plan, sino también realizar simulacros (訓練) en tiempos normales como preparación; no tiene que ver con procedimientos de adquisición ni con publicidad.

Una modificación del sistema (システム改修) representativa en la fase de operación es atender las revisiones del baremo de honorarios médicos (診療報酬改定). Cada revisión requiere modificar los maestros y la lógica de cálculo de los sistemas de facturación y de entrada de órdenes. Las modificaciones para la seguridad del paciente también se citan como típicas. Los logotipos, los menús del comedor y las tarifas del estacionamiento no son modificaciones representativas de un sistema de información hospitalaria.

La mejora continua (継続的な改善) empieza por definir qué medir y confirmar que puede medirse, y luego avanza por la recopilación de datos, su procesamiento y análisis, y la compilación y el uso de la información, hasta llegar a las acciones correctivas (是正活動). Las acciones correctivas nunca van primero, y sin analizar los datos recopilados no hay base para mejorar. Dar prioridad al statu quo contradice la idea de mejora continua.

Entre los efectos secundarios de la digitalización (情報化の副作用) se citan la pérdida parcial de comunicación al aumentar los intercambios a través de pantallas, la confusión por los cambios en el flujo de trabajo (ワークフロー), la confusión en la operación durante los fallos y la categorización inadecuada de la atención por el uso de plantillas. En realidad, la digitalización mejora la legibilidad y reduce los documentos manuscritos. Reducir a la mitad el consumo eléctrico no tiene nada que ver con el debate sobre los efectos secundarios.