Implantação e operação de sistemas

Um sistema de informação tem um ciclo de vida (ライフサイクル) que vai do planejamento e da aquisição à implantação, operação, avaliação e próxima atualização, e é importante refletir as avaliações feitas durante a operação no plano do próximo sistema. A implantação não é um evento único, e o termo não se refere apenas à vida útil (耐用年数) do hardware. A alternativa que ignora os resultados das avaliações também contraria o conceito de ciclo de vida.

Uma RFP (Request for Proposal, 提案依頼書) é um documento em que a instituição de saúde apresenta seus requisitos e condições de aquisição e pede aos fornecedores (ベンダ) que enviem propostas. Um documento que pede informações sobre produtos e tecnologias é uma RFI (solicitação de informações, 情報提供依頼書), usada na etapa anterior à definição dos requisitos. Um orçamento apenas com preço ou um documento de projeto detalhado posterior ao contrato não é uma RFP.

A aquisição (調達) primeiro esclarece os requisitos, depois estuda o método de aquisição e cria os critérios de avaliação dos fornecedores (ベンダ評価基準), em seguida prepara e emite a RFP e, por fim, avalia as propostas para selecionar o fornecedor e contratar. Uma ordem em que a emissão da RFP vem antes do esclarecimento dos requisitos, ou em que o contrato vem primeiro, é impossível. O ponto-chave é que os critérios de avaliação sejam preparados antes da emissão da RFP.

Uma especificação de requisitos (要求仕様書) é um documento em que a instituição de saúde esclarece os requisitos que exige do sistema e os comunica aos fornecedores para a aquisição. Ela descreve os requisitos básicos, os requisitos técnicos de hardware e software, os requisitos de conexão entre sistemas etc. Um relatório de conclusão da entrega, o código-fonte e os procedimentos de resposta a falhas não são especificações de requisitos.

Criar os critérios de avaliação (評価基準) antes de emitir a RFP permite comparar as propostas de forma justa e objetiva, com a mesma régua. Criar critérios depois de ver as propostas leva a uma avaliação arbitrária. Selecionar apenas pelo preço ignora a funcionalidade e a capacidade de manutenção, e dar informações extras a um determinado fornecedor prejudica a imparcialidade; por isso, essas práticas são inadequadas.

O leasing (リース) é uma modalidade em que o equipamento comprado por uma empresa de leasing é tomado em uso por longo prazo e, como regra, não pode ser rescindido antes do término. A locação (レンタル) destina-se ao uso de curto prazo e pode ser rescindida antes do término, o que a diferencia do leasing. No leasing, quem compra o equipamento e o registra como ativo é a empresa de leasing, não a instituição de saúde. O equipamento comprado torna-se ativo da instituição, mas não escapa do risco de obsolescência (陳腐化) devido ao progresso tecnológico.

A terceirização (業務委託) é um contrato em que a contratada executa o trabalho sob sua própria responsabilidade e direção; a instituição de saúde contratante não pode supervisionar diretamente os trabalhadores da contratada. No trabalho temporário (人材派遣), a instituição de saúde tomadora dirige os trabalhadores cedidos. Onde está o poder de direção (指揮命令権) é a diferença essencial entre os dois — não se trata apenas de uma diferença de nome.

A manutenção de software (ソフトウェア保守) abrange a correção de defeitos (bugs) descobertos após a entrada em operação e a aplicação de correções nos programas. Substituir ou consertar peças do servidor é manutenção de hardware (ハードウェア保守). Instalar cabos de LAN e remanejar terminais são trabalhos de construção e instalação, fora do escopo de um contrato de manutenção de software.

Para conectar vários sistemas, como o prontuário eletrônico e os sistemas departamentais, a especificação de requisitos deve indicar claramente os sistemas a serem conectados, os tipos de informação a serem trocados e o método de conexão (incluindo o uso de padrões, 標準規格), e esclarecer o escopo de responsabilidade. Decidir depois da entrada em operação, deixar a cargo dos fornecedores ou dispensar no caso de produtos do mesmo fornecedor leva a falhas de conexão e a uma responsabilidade pouco clara.

A implantação de um sistema de informação hospitalar faz parte de uma estratégia de TI (情報化戦略) baseada na estratégia de gestão (経営戦略); o envolvimento da direção e a construção de consenso são indispensáveis, e o diretor de informação na área da saúde (CIO da saúde, 医療CIO) lidera o planejamento e a promoção da estratégia. Decidir apenas dentro do departamento de TI carece de consenso. Os objetivos se diversificaram e incluem a melhoria da qualidade do atendimento e a cooperação, e a estratégia deve ser avaliada e revisada repetidamente.

Os cadastros mestres (マスター) de medicamentos, nomes de doenças, itens de exames, usuários etc. dependem muito da realidade da instituição, como os medicamentos que ela adota e suas regras de operação; por isso, a instituição de saúde deve participar ativamente de sua preparação. Eles não podem ser deixados a cargo do fornecedor, e o sistema não funcionará corretamente se não estiverem prontos antes da entrada em operação. Os cadastros mestres também exigem gestão contínua após a entrada em operação, por exemplo, para acompanhar as revisões dos preços dos medicamentos (薬価改定).

A fase de implantação passa pelo detalhamento das operações e especificações, pelo desenvolvimento, configuração e construção do sistema, pela criação dos dados mestres, pelos testes do sistema, pela migração de dados e pelo treinamento dos usuários; um teste operacional (ensaio) (運用テスト（リハーサル）) é realizado antes da entrada em operação, e o serviço começa após o aceite (検収). Ordens em que o aceite ou o ensaio vêm antes do detalhamento das especificações ou da criação dos dados mestres não fazem sentido.

Na migração de dados (データ移行), é importante decidir quais partes dos dados básicos do paciente e dos dados clínicos serão migradas, estudar o método de migração, realizá-la e depois verificar se os dados foram transferidos corretamente. Para manter a continuidade do atendimento, ela deve ser planejada e feita antes da entrada em operação; omitir a verificação ou descartar dados clínicos sem transferi-los é inadequado.

O aceite (検収) é o ato pelo qual a instituição de saúde contratante confirma que o sistema entregue funciona conforme a especificação de requisitos e o aceita; a entrega é concluída com o aceite. Os testes unitários internos do fornecedor fazem parte dos testes do sistema, o treinamento de operação é a capacitação dos usuários, e a análise das causas de falhas é uma atividade da fase de operação; nada disso é o aceite.

O teste operacional (ensaio) (運用テスト（リハーサル）) usa o sistema como em produção, seguindo o fluxo de trabalho real desde a recepção, passando por consultas e exames, até o pagamento, a fim de identificar problemas operacionais antes da entrada em operação. A revisão do código-fonte é um teste do lado do desenvolvimento, a estimativa de esforço pertence à etapa de aquisição e contrato, e medir a capacidade do ar-condicionado é uma questão de instalações; nada disso é finalidade do teste operacional.

Os grupos de trabalho (ワーキンググループ) reúnem representantes da linha de frente — médicos, enfermeiros, técnicos, funcionários administrativos — para detalhar as operações e especificações de cada departamento, conciliar as solicitações e avançar na construção de consenso (合意形成) dentro do hospital. Sua finalidade não é esconder o valor do contrato, nem substituir a tomada de decisão da direção (como os comitês), nem servir como medida de redução de pessoal.

Do lado do fornecedor, forma-se uma estrutura de projeto em torno de um gerente de projeto (プロジェクトマネージャ), com responsáveis por projeto, desenvolvimento e apoio à implantação, que se coordena com a estrutura correspondente da instituição de saúde. Um único representante de vendas não cuida de todas as fases. A estrutura é apresentada à instituição nas propostas e em outros documentos, e definir os responsáveis também é necessário para deixar claros os pontos de contato da coordenação.

Em implantações com vários fornecedores, como o prontuário eletrônico e os sistemas departamentais, é importante estabelecer antecipadamente mecanismos — como reuniões de coordenação — para a coordenação entre as áreas dentro do hospital, entre o hospital e os fornecedores e entre os fornecedores (ベンダ間の調整). Respostas improvisadas depois que os problemas ocorrem e a recusa em compartilhar as especificações de conexão levam a falhas de conexão. Os resultados da coordenação devem ser registrados e compartilhados.

Logo após o início do serviço (サービスイン), as dúvidas de operação e os problemas tendem a se concentrar; por isso, a equipe do fornecedor e do departamento de TI fica de prontidão no local e responde imediatamente (suporte na entrada em operação, 運用後立ち合い). Recusar-se a responder às falhas, suspender as contas logo após a entrada em operação e apagar imediatamente os dados do sistema antigo prejudicariam a continuidade do atendimento e a preservação dos dados, e são inadequados.

Os objetivos da implantação (導入目的) de um sistema de informação hospitalar se diversificaram além da eficiência administrativa e da cobrança ao seguro, incluindo a melhoria da qualidade e da segurança do atendimento, o uso na gestão e o apoio à cooperação regional (地域連携). Esclarecer o objetivo é uma condição prévia para redigir a especificação de requisitos e para a avaliação após a implantação; implantar sem objetivos definidos, ou reduzir o objetivo a um único item, não é adequado.

As regras de operação são organizadas em 3 camadas: a política (ポリシー), que expressa os princípios básicos; a norma (スタンダード), ou seja, o regulamento de gestão operacional que a torna concreta; e os procedimentos (プロシージャ), que definem as etapas do trabalho do dia a dia. Os procedimentos estão no nível dos manuais e as normas no nível dos regulamentos, não no da política básica. "Manifesto" não é um termo dessa estrutura de 3 camadas.

O regulamento de gestão operacional (運用管理規程) define os objetos e a estrutura da gestão, as responsabilidades dos administradores, dos responsáveis e dos usuários, o uso de servidores, terminais e redes, o tratamento e o armazenamento de dados, a capacitação e o treinamento, as medidas de segurança para trabalhos terceirizados, as disposições sobre penalidades etc. Uma lista dos diagnósticos de cada paciente é conteúdo dos registros clínicos e não pertence a um regulamento que define regras de operação.

Na gestão de usuários (ユーザ管理), o cadastro e a suspensão das contas devem estar vinculados às informações de recursos humanos, e a regra básica é suspender prontamente as contas de quem se desligou. Compartilhar IDs torna sem sentido o registro de quem fez o quê (a trilha de auditoria, 監査証跡), e deixar ativos os IDs de quem se desligou ou colar senhas nos terminais abre caminho para acessos não autorizados; tudo isso é inadequado.

O princípio da segregação (セグリゲーションの原則) separa autoridade e funções em vez de concentrá-las em 1 pessoa — por exemplo, fazendo com que o cadastro e a aprovação sejam feitos por pessoas diferentes — para que a verificação mútua evite fraudes e erros. Dar permissões de administrador a todos e unificar as senhas vão contra a gestão segura. Diferenciar os terminais por cores nada tem a ver com a segregação de funções.

Excluir um item do cadastro mestre faz com que os dados transacionais (トランザクションデータ) anteriores que o referenciam (como históricos de prescrição) não possam mais ser exibidos corretamente. Para preservar a consistência (整合性) entre o cadastro mestre e os dados transacionais, o item é desativado (uso suspenso) em vez de excluído. Reescrever o nome muda o significado dos registros anteriores, e não fazer nada leva a ordens erradas.

Em uma falha do sistema, avalie o alcance do impacto, avise prontamente os departamentos usuários e passe para a operação alternativa predefinida, como os procedimentos em papel (紙運用), para que o atendimento possa continuar. Após a recuperação, os registros feitos durante a operação alternativa são registrados retroativamente (遡及入力). Suspender todo o atendimento prejudica a continuidade do cuidado, e fazer o trabalho de recuperação sem avisar deixa a linha de frente sem condições de avaliar a situação e causa confusão.

O IT-BCP, como parte da gestão de continuidade de negócios (事業継続マネジメント) em uma instituição de saúde, é um plano para continuar e retomar rapidamente as operações essenciais mesmo durante desastres e falhas, enquanto a recuperação de desastres (ディザスターリカバリー) refere-se à restauração e reconstrução dos sistemas de informação danificados. É importante não apenas elaborar o plano, mas também realizar treinamentos em tempos normais como preparação; não se trata de procedimentos de aquisição nem de publicidade.

Uma modificação de sistema representativa na fase de operação é tratar as revisões da tabela de honorários médicos (診療報酬改定). Cada revisão exige modificar os cadastros mestres e a lógica de cálculo dos sistemas de faturamento e de entrada de ordens médicas. As modificações para a segurança do paciente (医療安全) também são citadas como típicas. Logotipos, cardápios do refeitório e tarifas de estacionamento não são modificações representativas de um sistema de informação hospitalar.

A melhoria contínua (継続的な改善) começa definindo o que medir e confirmando que pode ser medido, depois passa pela coleta, processamento e análise dos dados e pela consolidação e uso das informações, levando a ações corretivas (是正活動). As ações corretivas nunca vêm primeiro, e sem analisar os dados coletados não há base para a melhoria. Priorizar a manutenção da situação atual contraria a ideia de melhoria contínua.

Os efeitos colaterais da informatização (情報化の副作用) incluem a redução parcial da comunicação, à medida que mais trocas passam a ocorrer por meio de telas, a confusão causada por mudanças no fluxo de trabalho (ワークフロー), a confusão nas operações durante falhas e a categorização inadequada do atendimento pelo uso de modelos (templates). A digitalização, na verdade, melhora a legibilidade e reduz os documentos escritos à mão. Reduzir pela metade o consumo de energia elétrica nada tem a ver com a discussão sobre efeitos colaterais.