2
# mCockpitExternalViewerBridge
3
4
> Uma integração simples pode resolver um ponto real de atrito sem depender de desenvolvimento sob demanda do fornecedor da aplicação principal.
5
7
8
Projeto de integração entre o
mCockpit e viewers DICOM externos, como OsiriX e RadiAnt.9
10
Repositório: [rod-americo/mCockpitExternalViewerBridge](https://github.com/rod-americo/mCockpitExternalViewerBridge)
11
12
## Problema
13
14
O ponto de partida não era “criar um novo viewer” nem alterar a aplicação principal.
15
16
O problema era mais específico: em um fluxo real de uso, havia necessidade de abrir exames em viewers externos não contemplados pela própria aplicação, sem introduzir etapa manual no meio do caminho e sem depender de um pedido de customização ao fornecedor.
17
18
Em termos práticos, isso significava resolver quatro coisas ao mesmo tempo:
19
20
- receber a chamada feita pelo
mCockpit;21
- interpretar corretamente os argumentos enviados pelo plugin;
22
- abrir o exame no viewer externo configurado;
23
- manter o uso previsível no dia a dia.
24
25
## Recorte
26
27
O projeto é deliberadamente estreito.
28
29
Ele não tenta expandir o papel do
mCockpit, nem substituir o viewer principal, nem construir uma camada de integração genérica para qualquer cenário.30
31
O recorte é este:
32
33
- origem:
mCockpit34
- destino: viewers DICOM externos
35
- mecanismo: bridge local
36
- efeito esperado: reduzir atrito no fluxo de abertura de exames
37
38
## Solução
39
40
A solução foi criar uma bridge local:
mCockpitExternalViewerBridge.41
42
Essa bridge atua como camada de adaptação entre o ponto em que o
mCockpit dispara a abertura do exame e a forma como o viewer externo precisa receber essa informação.43
44
Na prática, a lógica faz quatro coisas:
45
46
1. recebe a chamada do sistema;
47
2. interpreta os argumentos relevantes, especialmente o
Accession Number;48
3. consulta a configuração local para decidir qual viewer usar;
49
4. redireciona a abertura para esse viewer.
50
51
O projeto foi pensado para trabalhar com dois caminhos principais:
52
53
-
RadiAnt, com abertura do estudo a partir de um diretório configurado;54
-
OsiriX ou Horos, com disparo de URL osirix://.55
56
## Decisão de arquitetura
57
58
A decisão principal aqui não foi “qual tecnologia usar”.
59
60
Foi escolher uma solução que:
61
62
- resolvesse uma necessidade muito localizada;
63
- não dependesse de mudança no roadmap do fornecedor;
64
- não exigisse alterar o fluxo diário de quem usa o sistema;
65
- pudesse ser implantada no ambiente local com controle direto da equipe.
66
67
Essa decisão reduz duas fontes de custo ao mesmo tempo:
68
69
- custo de fricção no uso diário;
70
- custo de depender de desenvolvimento customizado externo para uma demanda específica.
71
72
## Como entra no fluxo
73
74
O bridge é compilado como
ispilot.exe e colocado exatamente no caminho configurado no plugin do mCockpit.75
76
Isso permite que a aplicação continue chamando o executável esperado, enquanto a bridge assume a responsabilidade de interpretar os argumentos e redirecionar a abertura do exame.
77
78
O efeito desejado não é “sofisticação técnica”.
79
80
O efeito desejado é previsibilidade operacional.
81
82
## Ganho esperado
83
84
O ganho principal não está em acelerar benchmark, nem em criar nova funcionalidade clínica, nem em fazer marketing de integração.
85
86
O ganho esperado é mais simples:
87
88
- menos atrito na abertura de exames;
89
- menos improviso local;
90
- menos dependência de passos manuais;
91
- maior aderência entre a aplicação principal e o fluxo realmente usado.
92
93
## Limites atuais
94
95
O projeto assume um ambiente controlado e uma configuração local conhecida.
96
97
Os limites atuais incluem:
98
99
- parser simples de
config.ini;100
- convenções locais para montagem de caminho no
RadiAnt;101
- estratégia de logging ainda desativada;
102
- dependência de configuração correta do plugin do
mCockpit.103
104
## Síntese
105
106
mCockpitExternalViewerBridge não é um produto amplo.107
108
É uma solução específica para um ponto específico do fluxo.
109
110
E esse é justamente o seu valor: resolver integração suficiente para que o software pare de atrapalhar uma necessidade localizada de uso.