Integrações/Worklist e mapeamentos
Homologação

Worklist e mapeamentos

Envie pedidos e preserve a identificação do exame.

  • O Accession Number identifica o exame e deve ser único, com até 16 caracteres.
  • Um novo exame precisa de um novo Accession Number. Imagens complementares do mesmo estudo devem preservar o Study Instance UID.
  • Médicos executantes precisam estar cadastrados nos dois sistemas com CRM e UF correspondentes.
  • POST /v1/worklist aceita JSON e XML. A configuração administrativa permite mapear campos do fornecedor para os campos utilizados na agenda.
  • Fontes genéricas aceitas sem projeção ficam como RAW_ONLY; HTTP 201, isoladamente, não comprova que um item de agenda foi criado. Confira o diagnóstico no painel Worklist e mapeamentos.
  • O painel permite visualizar o recebimento original, testar o mapeamento e reprocessar a fonte. A prévia não cria exames.

Exemplo mínimo de envio com dados fictícios:

BASE='https://staging.themishealth.com.br'
TOKEN='substitua-pelo-token-de-homologacao'
curl --fail-with-body -X POST "$BASE/v1/worklist" \
  -H "token: $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "patient_name": "Paciente de Homologacao",
    "accession_number": "TESTE0001",
    "modality": "CT",
    "date_exam": "2026-09-20",
    "time_exam": "14:30:00"
  }'

Use uma data apropriada à homologação. Confira no OpenAPI os campos necessários ao formato escolhido e os limites dos corpos de requisição.

Mapeamentos por integração

A administração está em Unidades → Credenciais de API → Worklist e mapeamentos. Abra o formulário, salve a lista JSON declarativa e reabra para conferir. A prévia usa o mapeamento salvo e não grava recebimentos ou exames. A lista tem 20 itens por página; a fonte é carregada somente ao clicar em Ver recebimento. Processar com mapeamento usa o original retido e o adapter salvo selecionado.

Credenciais MobileMed recebem objetos genéricos com HTTP201 {}. A projeção válida gera PROJECTED; sem adapter explícito/padrão, fonte incompleta fica RAW_ONLY, com diagnóstico. Legacy exige seu DTO e mantém created201/noop200. Toda chamada aceita mantém um recebimento, inclusive noop. JSON conserva seu significado, sem promessa de bytes originais; XML conserva texto original e objeto parseado com raiz, atributos @_nome e elementos repetidos em arrays. DTD não é permitido. O limite HTTP existente é 100KB para JSON e 1MB para XML.

{
  "name": "hospital-a",
  "version": 1,
  "fields": {
    "PatientName": {"path": ["paciente", "nome"], "transforms": ["string", "trim"]},
    "AccessionNumber": {"path": ["pedido", "numero"], "transforms": ["string"]},
    "Modality": {"path": ["pedido", "modalidade"], "transforms": ["uppercase"]},
    "Date": {"path": ["pedido", "data"], "transforms": ["date:iso-to-dicom"]},
    "Time": {"path": ["pedido", "hora"], "transforms": ["time:colon-to-dicom"]},
    "ClinicalMarkings": {"path": ["marcacoes"]}
  },
  "defaults": {"Time": "000000"}
}

Até 20 adapters por cliente, 65536 bytes de JSON UTF-8 na configuração, nomes únicos de até 64 caracteres e versões 1..2147483647. mobilemed e kai são presets reservados somente para formatos conhecidos. Paths têm 1..16 propriedades/índices; transformações têm até 8 operações. Vocabulário: string, trim, uppercase, date:iso-to-dicom, time:colon-to-dicom ou {"enumMap":{"valor":"literal"}}. EnumMap admite até 100 entradas; valor sem correspondência recusa a projeção. Defaults são literais por campo. Nada executa JS ou expressões.

Alvos: PatientName, PatientId, PatientBirthdate, PatientSex, PatientCpf, AccessionNumber, Modality, StudyDescription, InsurencePlan, InsurancePlan, Date, Time, ReferringPhysician e ClinicalMarkings. Marcações usam os 14 IDs clínicos documentados e recusam contradições. Ausência preserva fatos; não se infere malignidade de BI-RADS. Worklist não assina nem importa laudos.

Reprocessamento de PROJECTED preserva a vinculação: accession, paciente, identidade, nascimento e modalidade não podem mudar. Campos clínicos, solicitante, convênio, sexo explícito, descrição sem conflito com catálogo e agendamento passam pelo update operacional. Mudança apenas dos segundos do agendamento é recusada, pois a edição operacional tem precisão de minuto. Laudo, assinatura, liberação e escopo dos links permanecem intactos. Recusas de validação deixam diagnóstico e tentativa com adapter/versão; fonte original e vínculo permanecem iguais. Falha operacional/SQL desfaz a transação inteira. Não há ingresso sintético.