1. Tabela de laudos
1.1. Definição de campos
1.2. Campos para atender ORM + ORU + CTRL
2. Checklist
2.1. 1. 4h para organização do pacote de scripts
2.2. 2. Campos obrigatórios
2.3. 3. Verificar ACCNO
2.4. 4. PAT_ID
2.5. 5. ORD_ID
2.6. 6. VIS_ID
2.7. 7. Procedimento existe?
2.8. 8. Sala de trabalho
2.9. 9. Solicitante
2.10. 10. Laudante
2.11. 11. Status da ordem
2.12. 12. Existe laudo no RIS
2.13. 13. Marcado para migração?
3. Requisitos
3.1. O cliente não pode mais reclamar de "instabilidade"
3.1.1. Qual a definição de "instabilidade" que leva o cliente a fazer laudo no HIS?
3.1.2. O cliente conhece procedimentos de reparo manual?
3.1.3. O cliente tem um RIS/PACS Admin?
3.1.4. Não há sentido em fazer uma migração se o sistema ainda estiver instável, esse é um procedimento manual e não uma integração.
3.2. Entrega de datos
3.2.1. Os laudos serão apresentados para migração na tabela RESULTADO_HIS
3.3. Laudos no PACS
3.3.1. Isso é automático, vai acontecer
3.3.2. Está propositalmente fora da lista de requisitos uma vez que é uma feature do RIS para qualquer laudo além de gerar confusão por fazer o cliente pensar que haverá vínculo com imagens.
3.4. Avanzar estado de CRISi
3.4.1. Atualizar status de ordem (ou criar)
3.4.1.1. Antes de atualizar, validar GRUPO
3.4.1.1.1. ACCNO - quando existir deve fazer parte do grupo correto
3.4.1.1.2. PAT_ID - quando existir deve respeitar o matching de nome, sobrenome e DOB
3.4.1.1.3. ORD_ID - quando existir deve respeitar grupo
3.4.1.1.4. VIS_ID - quando existir deve respeitar grupo
3.4.1.2. 24h
3.4.1.2.1. Se status < FIN enviar XO
3.4.1.2.2. Se status NULL enviar NW
3.4.1.2.3. Precisa de CA?
3.4.1.2.4. O envio será feito na fase 2
3.5. Campos mandatorios
3.5.1. Todos os campos mandatórios devem ser enviados pelo cliente
3.5.1.1. Significa que devem ser tratados pelo cliente seja preenchido manualmente ou por uma regra
3.5.1.2. A regra pode ser programada mas só será executado por autorização do cliente
3.5.1.3. Inicialmente campos mandatório serão NOT NULL
3.5.1.4. Sala de trabalho, caso não seja informada será a primeira relacionada ao procedimento.
3.5.1.4.1. 2h script de consulta
3.5.1.5. O solicitante deve existir no RIS
3.5.1.5.1. 2h script de consulta
3.5.1.6. O laudante deve existir no RIS
3.5.1.6.1. 2h script de consulta
3.5.1.7. O procedimento deve existir no RIS? nao necessário
3.5.1.7.1. 2h script de consulta
3.6. Reemplazar informes anteriores
3.6.1. O novo laudo deve substituir caso já exista
3.7. Utilizar DB_LINK entre os banco do HIS e RIS??
3.7.1. Definir owner de DB_LINK
3.7.2. 1h Se for no RIS
3.8. Checklist
3.8.1. Cada regra de verificação deve ter seu resultado gravado na tabela de import
3.9. Tabla alternativa de eventos
3.9.1. Todos os eventos de registros afetados na integração devem ser registrados em tabelas diferentes das atuais (TRACKING_ORDER e RESULTADO)
3.9.1.1. Migracion ONLINE
3.9.1.1.1. Sem DOWNTIME
3.9.1.2. Com DOWNTIME
3.9.1.2.1. Estratégia com downtime, a migração entra no fluxo normal e os seus dados serão exportados ao final do procedimento.
3.9.1.2.2. 30m para dev de scripts de export de delete