Skill de Relatório de Caso Clínico
Gere uma apresentação de caso clínico estruturada para rounds clínicos, conferências ou documentação. A saída segue convenções padrão de formatação médica usadas em ambientes hospitalares em todo o mundo.
O que será produzido
Um relatório de caso HTML de página única (index.html). O conteúdo varia conforme o formato (veja references/case-formats.md — selecionado na Etapa 0):
Formato SOAP / Conferência:
- Identificação do paciente — idade, sexo, queixa principal
- História da Doença Atual (HDA) — narrativa cronológica com positivos e negativos pertinentes
- História Médica Pregressa, Medicamentos, Alergias
- Revisão de Sistemas
- Exame Físico — achados sistemáticos por sistema
- Sinais Vitais — tabela formatada com faixas de referência e alertas
- Investigações — resultados laboratoriais e de imagem
- Avaliação — diagnóstico principal e diagnóstico diferencial (3–5 itens) com raciocínio clínico para cada um
- Plano de Manejo — baseado em evidências, organizado por problema
Formato Rounds Resumido (revisão diária, round de enfermaria, passagem de plantão, UTI, pós-plantão):
- Linha de identificação — idade, sexo, dia de internação, problema principal
- Eventos do intervalo / status atual — o que mudou desde a última revisão
- Problemas ativos — lista numerada
- Plano por problema — ações concisas para cada problema ativo
- A HDA completa e o exame físico sistemático não são incluídos
Fluxo de trabalho passo a passo
Etapa 0 — Carregar arquivos de referência
Antes de começar, leia ambos os arquivos de referência:
references/case-formats.md— use para escolher o formato de saída correto (SOAP, Conferência ou Rounds Resumido) com base no contexto do usuárioreferences/checklist.md— mantenha os portões P0 em mente durante todo o processo; você deve passar em todos os itens P0 antes de emitir o artefato final
Etapa 1 — Analisar o resumo
Leia o prompt do usuário e extraia:
- Idade e sexo do paciente
- Queixa principal ou problema de apresentação
- Quaisquer sinais vitais, exames laboratoriais ou de imagem que o usuário forneceu
- Contexto clínico: emergência, rounds de enfermaria, caso de conferência, ambulatório, etc.
- Contexto de especialidade: cardiologia, emergência, clínica médica, etc.
Se a queixa principal ou problema de apresentação estiver ausente:
- SOAP / Conferência: faça uma pergunta esclarecedora antes de prosseguir. Não prossiga sem ela.
- Rounds Resumido: se o problema de admissão ou a linha de identificação já estiver disponível (ex.: "revisão de UTI dia 3 para choque séptico"), prossiga diretamente — uma queixa principal separada não é necessária.
Etapa 2 — Construir a narrativa clínica
Para saídas SOAP / Conferência: escreva a HDA como uma narrativa em prosa contínua no estilo clínico padrão:
"Este é um paciente de [idade] anos, [sexo], com histórico de [HMP relevante] que se apresenta com [queixa principal]. Os sintomas começaram [cronologia] e são caracterizados por [qualidade, gravidade, irradiação]. Os sintomas associados incluem [lista]. Os negativos pertinentes incluem [lista]."
A HDA deve ser cronológica. Inclua marcadores de tempo ("2 horas antes da apresentação", "início ontem de manhã").
Para saídas de Rounds Resumido (revisão diária, round de enfermaria, passagem de plantão, UTI, pós-plantão): pule a HDA completa e o exame. Em vez disso, produza:
- Linha de identificação: "[Idade][sexo], Dia [N] de internação, [problema principal]"
- Eventos do intervalo / status atual: o que mudou desde a última revisão
- Problemas ativos: lista numerada
- Plano por problema: ação concisa para cada problema ativo
Etapa 3 — Gerar dados clínicos fisiologicamente consistentes
Se o usuário não forneceu valores específicos, gere valores que sejam internamente consistentes com o diagnóstico:
Verificações de consistência (padrões típicos):
- Um paciente em choque tipicamente apresenta: FC >100, PAS <90, lactato elevado, enchimento capilar prejudicado — mas medicamentos (betabloqueadores), idade ou tipo de choque (neurogênico, espinhal) podem alterar esse padrão
- Pneumonia tipicamente se apresenta com leucócitos elevados, PCR elevado, temperatura >38°C — mas pneumonia afebril existe, especialmente em idosos ou imunocomprometidos
- Um IAMCSST tipicamente mostra elevação de ST em derivações contíguas e troponina de alta sensibilidade elevada — mas apresentações precoces podem ter troponina inicialmente normal; CK-MB não é universalmente necessária
- Sepse tipicamente mostra leucócitos elevados ou baixos, lactato >2, anormalidade de temperatura — mas sepse precoce compensada pode se apresentar com sinais vitais normais
- As unidades de laboratório devem seguir a convenção: creatinina em µmol/L ou mg/dL (especificar qual), glicose em mmol/L, hemoglobina em g/dL
Regra crítica — preserve os dados fornecidos pelo usuário:
- Nunca sobrescreva um valor que o usuário tenha declarado explicitamente
- Se um valor fornecido pelo usuário for atípico para o diagnóstico, mantenha-o e observe a apresentação atípica na avaliação, em vez de forçar números canônicos
- Nunca gere um valor que contradiga o diagnóstico declarado
Etapa 4 — Escrever a avaliação
A seção de avaliação deve conter:
- Diagnóstico primário declarado claramente na primeira linha
- Raciocínio clínico — uma frase explicando por que este é o diagnóstico mais provável
- Diagnóstico diferencial — exatamente 3 a 5 itens, cada um com uma frase de evidência de apoio ou refutação
- Estratificação de risco — inclua um escore clínico validado quando aplicável (TIMI para SCA, GRACE para SCA, classe Killip + Índice de Choque para IAMCSST/choque cardiogênico, CURB-65 para pneumonia, qSOFA para sepse, Wells para TEP, etc.). A classe Killip e o Índice de Choque juntos são aceitos como estratificação de risco suficiente para casos de IAMCSST/choque cardiogênico.
Etapa 5 — Escrever o plano de manejo
O plano deve ser:
- Específico: escreva nomes de medicamentos, doses, vias e frequências. Não escreva "iniciar antibióticos" — escreva "Piperacilina-Tazobactam 4,5g IV a cada 8h por 5 dias"
- Organizado por problema usando cabeçalhos numerados
- Baseado em evidências: o manejo deve refletir o padrão atual de cuidado para o diagnóstico
- Completo: inclua investigações a solicitar, parâmetros de monitoramento, consultas a solicitar e disposição
Se você não tiver certeza sobre uma dose específica, escreva "[nome do medicamento] — dose conforme formulário/protocolo local" em vez de inventar uma dose.
Importante — Segurança na Prescrição
Os planos gerados devem:
- Ser marcados como educacionais/simulados, não um substituto para o julgamento clínico
- Usar a linguagem "conforme formulário/protocolo local" quando as variáveis do paciente necessárias (peso, função renal, alergias) estiverem ausentes do resumo
- Listar contraindicações e incógnitas importantes antes das recomendações de medicamentos quando dados relevantes do paciente não foram fornecidos
- Nunca afirmar que um plano é "definitivo" ou "padrão de cuidado" sem o contexto completo do paciente (status de alergia, função renal/hepática, status de gravidez, peso, risco de anticoagulação/sangramento)
- Incluir um rodapé de aviso na saída HTML afirmando que o caso é apenas para fins educacionais e de documentação
Etapa 6 — Escrever index.html
Requisitos para a saída HTML:
- Tipografia profissional de documento médico (fonte Georgia ou serif do sistema preferida)
- Fundo branco, texto escuro — adequado para impressão
- Sinais vitais e resultados laboratoriais em elementos HTML
<table> - Achados críticos (elevação de ST, troponina elevada, PA baixa, etc.) destacados em uma caixa de chamada visualmente distinta com borda esquerda vermelha
- Regras CSS @media print para que o documento seja impresso de forma limpa em A4/Carta
- Marque cada seção principal com
data-od-idpara direcionamento no modo de comentário:
<section data-od-id="hpi">...</section>
<section data-od-id="vitals">...</section>
<section data-od-id="pmh">...</section>
<section data-od-id="examination">...</section>
<section data-od-id="investigations">...</section>
<section data-od-id="assessment">...</section>
<section data-od-id="plan">...</section>
Etapa 7 — Auto-verificação contra references/checklist.md
Antes de emitir <artifact>, execute cada item P0 em references/checklist.md. Todos os itens P0 devem passar. Corrija quaisquer falhas antes de emitir.