CONCURSO PÚBLICO N.º 190026/21
Programa do Concurso E
Caderno de Encargos
Prestação de Serviços, Telerradiologia
CONCURSO PÚBLICO N.º 190026/21
Programa de Concurso
DISPOSIÇÕES INICIAIS
Artigo 1.º Objeto do Concurso
1. O objecto do presente CONCURSO é a Prestação de Serviços no âmbito da Telerradiologia nas áreas de TAC e RM, que serão prestados nas instalações do adjudicatário.
2. É condição de admissão a COBERTURA 24 HORAS/DIA, TODOS OS DIAS DO ANO.
3. A previsão anual de exames é de 19.934 (17.750 TAC e 2.184 RM).
4. A incidência percentual aproximada dos exames de TAC e RM vs horários é a constante do anexo I.
Artigo 2.º
Procedimento de contratação e órgão que tomou a decisão de contratar
O procedimento de contratação reveste a forma de um Concurso Público efetuado, nos termos da alínea a) do n.º 1 do artigo 20.º do Código dos Contratos Públicos (CCP), decreto-lei n.º 111-B/2017 de 31 de dezembro, e respetivas alterações.
Artigo 3.º
Entidade adjudicante e órgão que tomou a decisão de contratar
1. A Entidade Adjudicante é o Hospital do Espirito Santo de Évora (HESE), E.P.E., sito no Xxxxx Xxxxxx xx Xxxxxxx, 0000-000 Xxxxx.
2. A decisão de contratar foi tomada pelo Conselho de Administração do Hospital do Espírito Santo de Évora, E.P.E., nomeado pela Resolução n.º 39/2019 do Conselho de Ministros de 20 de fevereiro de 2019, publicado a 20 de fevereiro na 2.ª série do Diário da República.
Artigo 4.º Júri do concurso
O CONCURSO é conduzido por um júri, composto por elementos a designar pela ENTIDADE ADJUDICANTE, nos termos do artigo 67.º do CCP.
Artigo 5.º Peças concursais
O processo do CONCURSO é composto pelas seguintes peças:
a. O presente programa do CONCURSO;
b. O CADERNO DE ENCARGOS;
c. Lista de quantidades (anexo I).
Artigo 6.º
Consulta do processo de concurso
As peças do concurso, conforme o artigo 5.º, encontram-se disponíveis de forma livre, completa e gratuita na Plataforma Eletrónica Vortalnext, e onde podem ser consultadas desde a data da primeira publicação do anúncio.
Artigo 7.º
Esclarecimentos, Retificações e Alteração das Peças Procedimentais
1. No primeiro terço do prazo fixado para a apresentação das propostas, os interessados podem solicitar os esclarecimentos necessários à boa compreensão e interpretação das peças do procedimento, previstas no artigo 5.º, e no mesmo prazo, devem apresentar uma lista na qual identifiquem, expressa e inequivocamente, os erros e as omissões das peças do procedimento por si detetados.
2. Consideram-se erros e omissões das peças procedimentais os constantes no n.º 2 do artigo 50.º do CCP. A lista a apresentar ao órgão competente para a decisão de contratar deve identificar, expressa e inequivocamente, os erros e omissões do caderno de encargos detetados.
3. Os esclarecimentos a que se refere no n.º 1, serão prestados até ao termo do segundo terço do prazo fixado para a apresentação das propostas. Por delegação de competências do órgão competente para a decisão de contratar, são prestados pelo júri do procedimento.
4. O órgão competente para a decisão de contratar pronuncia-se sobre os erros e omissões até ao termo do segundo terço do prazo fixado para a apresentação das propostas, onde deve identificar os termos do suprimento de cada um dos erros ou das omissões aceites.
5. Independentemente do disposto nos números anteriores, o órgão competente para a decisão de contratar pode, oficiosamente, proceder à retificação de erros ou omissões das peças do procedimento, bem como prestar esclarecimentos, no prazo referido no n.º 1, ou até ao final do prazo de entrega das propostas, devendo, neste caso, prorrogar o prazo fixado para apresentação das propostas.
6. Os esclarecimentos, as retificações e as listas com a identificação dos erros e omissões detetados pelos interessados devem ser disponibilizados na plataforma eletrónica Vortalnext e juntos às peças do procedimento que se encontrem patentes para consulta, devendo todos os interessados que as tenham obtido ser imediatamente notificados desse facto.
7. Os esclarecimentos e as retificações fazem parte integrante das peças concursais a que dizem respeito e prevalecem sobre estes em caso de divergência.
Artigo 8.º
Prazo e modo de apresentação de propostas
1. As propostas e os documentos que as acompanham devem ser apresentados até às 18h00m inclusive, do 30.º dia a contar da data do envio do anúncio ao Serviço de Publicações Oficiais das Comunidades Europeias.
2. Os documentos que constituem a proposta deverão ser apresentados na plataforma eletrónica utilizada pela Entidade Adjudicante e deverá estar assinada em cumprimento do disposto na Lei n.º 96/2015, de 17 de agosto. A aposição de assinatura eletrónica qualificada deve ocorrer em cada um dos documentos eletrónicos que constituem a proposta
3. Nos casos em que o certificado digital não relacione diretamente o assinante com a sua função e poder de assinatura, deve o concorrente submeter na plataforma o documento eletrónico oficial indicando o poder de representação e assinatura do assinante.
4. Em proposta apresentada por um agrupamento concorrente, a proposta deve ser assinada pelo representante comum dos membros que o integram, caso em que devem ser juntos à proposta os instrumentos de mandato emitidos por cada um dos seus membros ou, não existindo representante comum, deve ser assinada por todos os seus membros ou respetivos representantes.
5. A proposta deve ser assinada pelo concorrente ou seus representantes, que tenham poderes para o obrigar. Sempre que a proposta seja assinada pelo procurador, juntar-se-á a procuração que confira a este esse efeito, devidamente legalizada.
6. O não cumprimento dos números anteriores é motivo de exclusão da proposta.
Artigo 9.º Preço Base
1. O preço base deste procedimento é de 429.362,00 € e constitui o preço máximo que a entidade adjudicante está disposta a pagar pela execução de todas as prestações que constituem o objeto do contrato a celebrar.
2. O preço referido no número anterior inclui todos os custos, encargos e despesas cuja responsabilidade não esteja expressamente atribuída ao Hospital, sendo aquele preço global máximo desagregado da seguinte forma:
a. de 1 de janeiro de 2021 até 31 de dezembro de 2021: valor máximo previsto da adjudicação de
429.326,00 €.
Artigo 10.º Proposta
1. Na proposta, o concorrente que manifesta a sua vontade de contratar e terá de apresentar os documentos abaixo identificados:
a) Documento Europeu Único de Contratação Pública (DEUCP), disponível online através do portal da Comissão Europeia em xxxx://xxx.xxxx.xxx.xx/xxxxx/xxxxxx?xxxxxxx
b) Declaração de aceitação do conteúdo do Caderno de Encargos conforme o modelo no Anexo II do Caderno de Encargos;
c) Apresentação de preços:
I. Preço unitário – por algarismos e por extenso;
II. Preço global – valor total da proposta correspondente à soma dos vários itens – por algarismo e por extenso, acrescida do valor do IVA à taxa legal em vigor;
d) Identificação dos médicos e apresentação dos seguintes docuemntos:
I. Cartão da ordem dos médicos;
II. Curriculum vitae (versão resumida);
e) Declaração de compromisso de honra em que o prestador de serviço cumpre do disposto Portaria n.º 35/2014, de 12 de fevereiro;
f) Cópia do Certificado de licença de Funcionamento emitido pela Entidade Reguladora da Saúde (ERS);
g) Manual de especificações técnicas do interface com o RIS/PACS, existente no HESE;
h) Documentos que certifiquem a conformidade da existência de seguro de responsabilidade civil da empresa;
2. Na proposta o concorrente pode especificar aspetos que considere relevantes para a apreciação da mesma.
3. Os documentos que constituem a proposta são obrigatoriamente redigidos em língua portuguesa.
4. A falta dos documentos solicitados no número anterior é motivo de exclusão da proposta.
Artigo 11.º Indicação do preço
1. Os preços constantes da proposta são indicados em algarismos e não incluem o IVA.
2. Quando os preços constantes da proposta forem também indicados por extenso, em caso de divergência, estes prevalecem, para todos os efeitos, sobre os indicados em algarismos.
Artigo 12.º
Propostas variantes, parciais ou condicionadas
1. Não são admitidas propostas variantes, propostas parciais, e propostas condicionadas.
2. O não cumprimento do número anterior é motivo de exclusão da proposta.
Artigo 13.º
Prazo de manutenção das propostas
1. Os concorrentes são obrigados a manter as suas propostas durante um prazo de 66 (sessenta e seis) dias, contados a partir da data limite de apresentação das mesmas.
2. Todas as entidades agrupadas são responsáveis, nos termos do número anterior, pela manutenção da proposta que apresentem.
Artigo 14.º
Adjudicação de proposta apresentada por um agrupamento
1. Se a adjudicação recair em proposta apresentada por um agrupamento, as entidades que o compõem devem, depois de lhe ser notificada a adjudicação, mas antes da celebração do CONTRATO, associar-se na modalidade de consórcio externo, em regime de responsabilidade solidária, nos termos do disposto no decreto-lei n.º 231/81, de 28 de julho.
2. O contrato de consórcio deve indicar a entidade que exercerá a função de líder de consórcio, devendo ser-lhe conferidos, no mesmo ato, e por procuração, os poderes referidos no n.º 1 do artigo 14.º do decreto-lei n.º 231/81, de 28 de julho, e ainda os poderes especiais para receber da ENTIDADE ADJUDICANTE, e delas dar quitação, quaisquer quantias que devam ser pagas às consorciadas em execução do CONTRATO.
ANÁLISE E AVALIAÇÃO DAS PROPOSTAS
Artigo 15.º Apreciação das propostas
1. As propostas apresentadas serão em seguida analisadas e avaliadas pelo júri do CONCURSO.
2. O júri elaborará um relatório preliminar fundamentado sobre a análise das propostas, ordenando-as segundo o seu valor global, de acordo com o critério de adjudicação.
3. O júri deve, no mesmo relatório, propor a exclusão das propostas cuja análise revele alguma das situações previstas no n.º 2 do artigo 70.º do CCP e nos nºs 2 e 3 do artigo 146.º do CCP.
Artigo 16.º
Esclarecimentos a prestar pelos concorrentes
1. Os concorrentes obrigam-se a prestar, relativamente às respetivas propostas e a todos os documentos que as instruam, os esclarecimentos que o júri do CONCURSO considere necessários para efeitos da sua análise e avaliação.
2. O incumprimento às solicitações a que se refere o ponto 1, no prazo concedido para o efeito, determina a exclusão da proposta.
Artigo 17.º Audiência prévia
1. O Júri do concurso deve, antes de proferida a decisão final de adjudicar e para elaborar o relatório final, proceder à audiência prévia escrita dos concorrentes.
2. Os concorrentes têm 5 (cinco) dias, após a notificação do relatório preliminar, para se pronunciarem.
Artigo 18.º Critério de adjudicação
1. O critério no qual se baseará a apreciação das propostas e a subsequente adjudicação será o da proposta economicamente mais vantajosa de acordo com o interesse público, atendendo aos seguintes fatores de apreciação e respetivos coeficientes de ponderação:
a) Fator Preço, com a ponderação de 80% considerando a seguinte fórmula de aplicação: em que:
Preço Total (PT) – análise do preço do serviço apresentado por cada concorrente, para cada exame analisado, de acordo com a tabela de distribuição por variáveis de custo.
Em que:
• PVC – Inclui o tipo de exame (TAC e RM) e a prioridade dos exames (urgente II, urgente I e normal).
• NE – Quantidade de exames a realizar por tipo de exame.
b) Fator prazo de resposta, com a ponderação de 20%, dividido nos seguintes subfactores:
I. Prazo de resposta em exames Urgentes, conforme intervalos definidos, 10%
i. ≤ 30 Minutos - 100 pontos;
ii. [31; 60] minutos - 50 pontos;
iii. [61;80] Minutos - 25 pontos.
II. Prazo de resposta para exames não urgentes de doentes internados, 10%
i. ≤ 5 horas - 100 pontos;
ii. [5; 6] horas - 50 pontos;
iii. ]6; 7] horas - 25 pontos.
III. O prazo de resposta para exames de doentes não internados, não poderá ser superior a 72 horas.
2. Para efeitos de admissão das propostas, são definidos os seguintes valores de preço base, por prioridade:
Variáveis de Custo | Preço por variável de Custo (PVC) | |
Tipo de Exame | Prioridade | |
TAC | Normal | 19,00 € |
Urgente I | 21,00 € | |
Urgente II | 28,00 € | |
RM | Normal | 25,00 € |
Urgente I | 30,00 € | |
Urgente II | 35,00 € | |
Proposta | Dias úteis | Fim-de Semana e Feriados | |||||
00h - 08h | 08h-20h | 20h - 24h | 00h - 08h | 08h - 24h | |||
(a) | (b) | (c) | (d) | (e) | |||
TAC | Preço por Período | Base | 28,00 € | 19,00 € | 21,00 € | 28,00 € | 21,00 € |
RMN | Preço por Período | Base | 35,00 € | 25,00 € | 30,00 € | 35,00 € | 30,00 € |
Legenda:
a. = Prioridade Urgente II
b. = Prioridade Normal
c. = Prioridade Urgente I
d. = Prioridade Urgente II
e. = Prioridade Urgente I
3. Serão excluídas as propostas que apresentem, em qualquer um dos parâmetros atrás indicados, preço superior ao preço base indicado.
4. Em caso de empate, o fator de desempate será o da proposta que apresente o menor preço para a TAC prioridade Normal.
a. Caso subsista o empate, o fator de desempate será o da proposta que apresente menor preço para a TAC Urgente I;
b. Se o empate se mantiver, o fator de desempate será o da proposta que apresente menor preço para o exame RM prioridade Normal;
c. Se a situação de empate persistir, o fator de desempate será a proposta selecionada na sequência de sorteio a desenrolar presencialmente com os interessados, do qual será lavrada ata por todos os presentes.
DISPOSIÇÕES FINAIS
Artigo 19.º Documentos de habilitação
1. O adjudicatário deve apresentar os seguintes documentos de habilitação no prazo de 10 (dez) dias:
a. Declaração emitida conforme modelo constante do Anexo III;
b. Documentos comprovativos de que não se encontra nas situações previstas nas alíneas b), d), e) e i) do artigo 55.º do CCP;
c. Cópia de seguro de responsabilidade civil do profissional médico, adequado e válido.
2. O Adjudicatário deve apresentar reprodução dos documentos de habilitação referidos no número anterior na plataforma eletrónica utilizada pela Entidade Adjudicante. Caso os documentos não venham em língua portuguesa, deve o Adjudicatário fazê-los acompanhar de tradução devidamente legalizada.
3. Quando os documentos a apresentar se encontrem disponíveis na Internet, o Adjudicatário pode, em substituição da apresentação da sua reprodução, indicar à Entidade Adjudicante o endereço do sítio onde aqueles podem ser consultados, bem como a informação necessária a essa consulta, desde que os referidos sítio e documentos dele constantes estejam redigidos em língua portuguesa.
4. Sempre que sejam detetadas irregularidades nos documentos apresentados, que possam levar à caducidade da adjudicação, a Entidade Adjudicante concede um prazo de 3 (três) dias úteis, contados da data de notificação, para que o Adjudicatário as possa suprir.
5. Quando o Adjudicatário for um agrupamento de pessoas singulares ou coletivas, os diversos membros do agrupamento devem apresentar os documentos referidos na alínea a) e b) do n.º 1 do presente artigo, bem como os documentos referidos na Portaria n.º 372/2017 de 14 de dezembro, caso a atividade por esse membro desenvolvida requeira a titularidade dos referidos alvarás, licenças e autorizações.
6. Todos os concorrentes serão notificados em simultâneo da apresentação dos documentos de habilitação pela Entidade Adjudicante com indicação do dia em que ocorreu essa apresentação e os documentos da habilitação apresentados pelo Adjudicatário serão disponibilizados, para consulta de todos os concorrentes, na PLATAFORMA.
Artigo 20.º Caução
1. Para garantir o exato e pontual cumprimento de todas as obrigações legais e contratuais, será exigida ao Adjudicatário caução no valor de 5 % do preço contratual, se aplicável.
2. O Adjudicatário deve, no prazo de 10 (dez) dias úteis a contar da data da receção da notificação da adjudicação comprovar que prestou a caução.
3. A Entidade Adjudicante pode considerar perdida a seu favor a caução prestada, independentemente de decisão judicial, nos casos de não cumprimento das obrigações legais, contratuais ou pré-contratuais, pelo Adjudicatário.
Artigo 21.º
Modo de Prestação da Caução
1. A caução pode ser prestada por depósito em dinheiro ou em títulos emitidos ou garantidos pelo Estado, ou ainda mediante garantia bancária autónoma e irrevogável e à primeira solicitação ou por seguro- caução equivalente, conforme escolha do Adjudicatário.
2. Quando o depósito for efetuado em títulos, estes são avaliados pelo respetivo valor nominal, salvo se, nos últimos três meses, a média da cotação na bolsa de valores ficar abaixo do par, caso em que a avaliação é feita em 90% dessa média.
3. Se o Adjudicatário optar por prestar a caução mediante garantia bancária deverá ser apresentado um documento pelo qual o estabelecimento bancário legalmente autorizado assegure, até ao limite do valor da caução, o imediato pagamento de quaisquer importâncias exigidas pela entidade adjudicante em virtude do incumprimento de quaisquer obrigações a que a garantia respeita.
4. Se o Adjudicatário optar pelo seguro-caução, então este deverá apresentar apólice pela qual uma entidade legalmente autorizada a realizar esse seguro assuma, até ao limite do valor da caução, o encargo de satisfazer de imediato quaisquer importâncias exigidas pela Entidade Adjudicante em virtude do incumprimento de quaisquer obrigações a que o seguro respeita.
5. Das condições da garantia bancária ou da apólice de seguro-caução não pode, em caso algum, resultar uma diminuição das garantias para a Entidade Adjudicante, nos moldes em que são asseguradas pelas outras formas admitidas de prestação da caução.
6. Todas as despesas derivadas da prestação da caução ou do seguro da execução do contrato são da responsabilidade do Adjudicatário.
Artigo 22.º Minuta do contrato
1. A minuta do contrato é aprovada pelo órgão competente para a decisão de contratar em simultâneo com a decisão de adjudicação.
2. Considera-se a minuta do contrato aceite pelo Adjudicatário quando haja aceitação expressa ou quando não haja reclamação nos 5 (cinco) dias úteis subsequentes à respetiva notificação.
3. As reclamações da minuta do contrato a celebrar só podem ter por fundamento a previsão de obrigações que contrariem ou que não constem dos documentos que integram o CONTRATO ou ainda a recusa dos ajustamentos propostos.
4. No prazo de 10 (dez) dias úteis a contar da receção da reclamação, o órgão que aprovou a minuta do contrato notifica o Adjudicatário da sua decisão, equivalendo o silêncio à rejeição da reclamação.
5. Os ajustamentos propostos que tenham sido recusados pelo Adjudicatário não fazem parte integrante do contrato.
Artigo 23.º Caducidade da Adjudicação
1. A adjudicação caduca, por facto imputável ao Adjudicatário, nomeadamente:
a. Pela não apresentação dos documentos de habilitação no prazo exigido, conforme o artigo 86.º do CCP;
b. Pela falsificação de qualquer documento de habilitação ou pela prestação culposa de falsas declarações, nos termos dispostos do artigo 87.º do CCP;
c. Pela não prestação da caução após a notificação da adjudicação pelo órgão competente para a decisão de contratar, conforme o artigo 91.º do CCP;
d. O Adjudicatário não assinar o contrato e se no caso de um agrupamento o mesmo não se tiver associado nos termos do n.º 4 do artigo 54.º do CCP, seguindo-se quanto ao mais o regime previsto nos n.ºs 1 e 2 do artigo 105.º do CCP;
e. A ocorrência superveniente de circunstâncias que inviabilizem a celebração do contrato, designadamente por impossibilidade natural ou jurídica, extinção da entidade adjudicante ou do adjudicatário ou por insolvência deste, por força do artigo 87.º-A do CCP.
2. A decisão de não adjudicação, bem como os restantes fundamentos, será notificada a todos os concorrentes através da Plataforma Eletrónica Vortalnext, pelo órgão competente para a decisão de contratar.
Artigo 24.º
Despesas da elaboração da proposta
Todas as despesas inerentes à elaboração e apresentação das propostas constituem encargo do concorrente.
Artigo 25.º Legislação aplicável
A tudo o que não esteja especialmente previsto no presente Programa do Concurso aplica-se o regime previsto no Código dos Contratos Públicos, aprovado pelo decreto-lei n.º 111-B/2017 de 31 de agosto, na atual redação e respetivas alterações.
Caderno de Encargos
Artigo 1.º Objeto do Contrato
1. O presente Caderno de Encargos compreende as cláusulas a incluir no contrato a celebrar na sequência do procedimento pré-contratual que tem por objeto a aquisição de prestação de serviços de telerradiologia, para o ano 2021, de acordo com as condições e especificações previstas no presente caderno de encargos, nas cláusulas técnicas e no Anexo I.
2. As quantidades definidas pelo Contraente Público, no Anexo I do Caderno de Encargos, são meramente indicativas e tiveram em consideração os consumos realizados durante o ano 2020. Caso existam circunstâncias impostas pela tutela que impliquem a diminuição da atividade, o HESE adequará as suas aquisições, sem haver lugar a qualquer indemnização, por não aquisição da quantidade prevista.
3. A execução total ou parcial do presente procedimento está condicionada ao respetivo cabimento orçamental atribuído aquando a aprovação do Orçamento para 2021.
Artigo 2.º Prazo de Vigência
O objeto do concurso terá como período de vigência de 01 de janeiro de 2021 até 31 de dezembro de 2021.
Artigo 3.º Preço Contratual
1. Entende-se por preço contratual o preço a pagar pelo Contraente Público, em resultado da proposta adjudicada, pela execução de todas as prestações que constituem o objeto do contrato, nos termos do n.º 1 do artigo 97.º do CCP, acrescido de IVA à taxa legal em vigor, se aplicável.
2. O Contraente Público obriga-se a pagar por todas as obrigações prestadas pelo Co-contratante, os seguintes montantes:
− De 1 de janeiro de 2021 até 31 de dezembro de 2021: valor máximo previsto da adjudicação de 429.326,00 €;
3. O preço contratual inclui todos os custos, encargos e despesas cuja responsabilidade não esteja expressamente atribuída ao Contraente Público, nomeadamente os relativos ao transporte dos bens objeto do contrato para o respetivo local de entrega, seguros, fretes, taxas alfandegárias, instalação, montagem, demonstração das especificações técnicas, ensaio de todos os bens fornecidos e manutenção de meios materiais, bem como quaisquer encargos decorrentes da utilização de marcas registadas, patentes ou licenças.
Artigo 4.º
Documentos integrantes do Contrato
1. O CONTRATO integra os seguintes documentos:
a. O clausulado contratual;
b. Os suprimentos dos erros e das omissões do Caderno de Encargos identificados pelos concorrentes que tenham sido expressamente aceites pela ENTIDADE ADJUDICANTE;
c. Os esclarecimentos e as retificações relativas ao Caderno de Encargos;
d. O presente Caderno de Encargos;
e. A Proposta Adjudicada;
f. Os esclarecimentos sobre a PROPOSTA prestados pelo ADJUDICATÁRIO durante o procedimento concursal.
2. A ENTIDADE ADJUDICANTE pode excluir expressamente do CONTRATO os termos ou condições constantes da PROPOSTA que se reportem a aspetos de execução do CONTRATO não regulados pelo presente Caderno de Encargos e que não sejam considerados estritamente necessários à sua execução, ou sejam considerados desproporcionados.
3. Em caso de divergência entre os documentos que integram o CONTRATO designados nas alíneas
b) a f) do n.º 1 a prevalência obedece à ordem por que aí vêm enunciados.
4. Em caso de divergência entre os documentos referidos no número anterior e o clausulado contratual, prevalecem os primeiros, salvo quanto aos ajustamentos propostos de acordo com o disposto no artigo 99.º do CCP e aceites pelo ADJUDICATÁRIO nos termos do disposto no artigo 101.º do mesmo código.
5. Os aditamentos ao CONTRATO devem estabelecer a sua própria prevalência relativamente aos restantes documentos.
Artigo 5.º
Aspetos submetidos à concorrência
Nos termos do artigo 42.º do CCP, os aspetos submetidos à concorrência são o preço e o prazo de resposta.
Artigo 6.º
Aspetos não submetidos à concorrência
1. Nos termos do n.º 5 do artigo 42.º do CCP, os concorrentes devem observar nas suas propostas, e como eventuais futuros Co-contratantes, garantir, sem encargos adicionais para o Contraente Público, os aspetos não submetidos à concorrência referidos no Clausulado Técnico do presente Caderno de Encargos.
2. O incumprimento dos pressupostos no Clausulado Técnico implica a exclusão da proposta apresentada.
3. Esta prestação de serviços não pode contemplar médicos em funções no HESE, independentemente do vínculo laboral ou seja, os relatórios dos exames não poderão ser realizados por médicos afetos ao HESE.
Artigo 7.º Faturação
1. O Contraente Público não concederá qualquer adiantamento de preço por conta de prestações a realizar ou atos preparatórios ou acessórios das mesmas.
2. A fatura deverá ser emitida mensalmente e enviada para o Serviço de Aprovisionamento – Stocks, do Hospital do Espírito Santo de Évora, E.P.E., ou por outro meio de comunicação desde que acordado entre as duas partes, devendo incluir a seguinte informação:
a. O número da Nota de Encomenda e o número de compromisso;
b. Listagem detalhada de exames realizados com indicação do nome do utente, data e hora do exame, origem do doente, id do exame, designação do exame e o respetivo preço unitário. Esta informação deverá ser disponibilizada igualmente num ficheiro em excel a enviar mensalmente ao HESE para o endereço xxx.xxxxxxxxxxx@xxxxxx.xxx-xxxxx.xx .
3. Não há lugar a faturação adicional, para além do determinado no presente Caderno de Encargos.
4. Nas situações em que as faturas não apresentem os dados conforme referidos no n.º 2, o Co- contratante não poderá reclamar ao Contraente Público o respetivo pagamento.
5. Em caso de discordância por parte do Contraente Público, quanto aos valores indicados nas faturas, deve esta comunicar ao Co-contratante por escrito, os respetivos fundamentos, ficando o Co-contratante obrigado a prestar os esclarecimentos necessários ou proceder à emissão de Nota de Crédito.
6. Desde que devidamente emitidas e observado o disposto nos números anteriores, as faturas são pagas através de transferência bancária para o NIB indicado pelo Co-contratante.
Artigo 8.º Prazo de Pagamento
1. O prazo de pagamento é de 60 (sessenta) dias de calendário a contar da data de entrada da fatura nas instalações do Contraente Público, a qual só pode ser emitida após o vencimento da obrigação e emissão da respetiva nota de encomenda. A nota de encomenda será emitida pelo período de determinação dos fundos disponíveis, nos termos previstos no n.º 2 do artigo 8.º do decreto-lei n.º 127/2012, de 21 de junho, sendo nela necessariamente inscrito, sob pena de nulidade, um número de compromisso válido e sequencial.
2. Para os efeitos do número anterior, a obrigação considera-se vencida com o fornecimento dos bens objeto do contrato.
3. O HESE reserva-se o direito de descontar aos pagamentos mencionados o valor das penalidades em que o Co-contratante, nos termos do presente Caderno de Encargos.
4. Em caso de discordância por parte do Contraente Público, quanto aos valores indicados nas faturas, deve este comunicar ao fornecedor, por escrito, os respetivos fundamentos, ficando o Co-contratante obrigado a prestar os esclarecimentos necessários ou proceder à emissão de nota de crédito.
Artigo 9.º Atrasos nos Pagamentos
1. Salvo se o atraso não for lhe for imputável, o HESE, E.P.E., está obrigado ao pagamento de juros de mora, sempre que exista atraso no cumprimento das obrigações pecuniárias, ao adjudicatário sobre o montante em dívida à taxa legalmente fixada pela Direção Geral do Tesouro e Finanças pelo período correspondente à mora, nos termos previstos no artigo 326.º do CCP e da Lei n.º 3/2010, de 27 de Abril.
2. Em caso de incumprimento imputável ao HESE, E.P.E., o adjudicatário, independentemente do direito de resolução do contrato, nos termos do disposto no artigo 332.º do CCP, pode invocar a exceção de não cumprimento nos termos do 327.º do mesmo código.
3. O presente artigo apenas é aplicável, conforme disposto no artigo 12.º do decreto-lei n.º 62/2013.
Artigo 10.º Adiantamentos
A ENTIDADE ADJUDICANTE não concederá qualquer adiantamento.
Artigo 11.º
Subcontratação e Cessão da posição contratual
1. O Co-contratante não pode subcontratar e/ou ceder, total ou parcialmente, a sua posição contratual ou qualquer dos direitos e obrigações decorrentes do contrato, sem prévia autorização do Contraente Público.
2. Salvo autorização, o subcontratado e/ou cessionário proposto pelo Co-contratante deve apresentar toda a documentação exigida associada às condições de qualificação do Programa do concurso.
3. Para efeitos da autorização prevista no n.º 1, o Contraente Público deve apreciar, nomeadamente, se o subcontratado e/ou cessionário não se encontra em nenhuma das situações impeditivas previstas no artigo 55.º do CCP e a existência ou não de indícios de que a
cessão da posição contratual ou a subcontratação resultem de atos, acordos, práticas ou informações suscetíveis de falsear as regras da concorrência.
4. A autorização da subcontratação e/ou da cessão da posição contratual pelo Contraente Público depende, também, do disposto no n.º 2 e n.º 3 do artigo 318.º do CCP.
5. Nos casos de subcontratação, o Co-contratante é integralmente responsável perante o Contraente Público pelo exato e pontual cumprimento de todas as obrigações contratuais, nos termos do 321.º do CCP.
Artigo 12.º Outros encargos
Todos os encargos e despesas legais com a celebração do CONTRATO são da responsabilidade do ADJUDICATÁRIO.
Artigo 13.º Responsabilidade extracontratual
1. O ADJUDICATÁRIO responde, nos termos gerais de direito, por quaisquer danos causados no âmbito do CONTRATO, pela culpa ou pelo risco.
2. O ADJUDICATÁRIO responde igualmente, nos termos em que o comitente responde pelos atos do comissário, pelos prejuízos causados por terceiros contratados no âmbito do CONTRATO.
3. Pelas multas e indemnizações a pagar pelos prejuízos causados respondem, em primeiro lugar, as importâncias que o ADJUDICATÁRIO tenha a receber, em segundo lugar, as cauções e, finalmente, os restantes bens do ADJUDICATÁRIO.
Artigo 14.º
Casos fortuitos ou de força maior
1. Nenhuma das partes incorrerá em responsabilidade se, por caso fortuito ou de força maior, for impedido de cumprir as obrigações assumidas no CONTRATO.
2. Nenhuma das partes incorrerá em qualquer obrigação de indemnizar, compensar ou ressarcir a outra por quaisquer prejuízos incorridos ou a incorrer para cumprimento das suas obrigações contratuais por força de caso fortuito ou de força maior.
3. Para os efeitos dos números anteriores, considera-se caso de força maior o facto praticado por terceiro pelo qual a parte não seja responsável, direta ou indiretamente, ou que, para a sua verificação, não tenha comprovadamente contribuído, bem como qualquer facto natural, situação imprevisível ou inevitável cujos efeitos se produzam independentemente da vontade ou das circunstâncias pessoais das partes, nomeadamente:
a. Atos de guerra ou de subversão;
b. Epidemias;
c. Ciclones;
d. Tremores de terra, fogo, raios, inundações que afetem as instalações ou a capacidade produtiva das partes;
e. Greves gerais ou sectoriais que impliquem quebra total da capacidade produtiva das partes.
4. A parte que invocar casos fortuitos ou de força maior que impeçam o cumprimento total ou parcial do CONTRATO ou que impliquem atrasos ou prejuízos na execução do CONTRATO ou o agravamento do seu custo deve comunicar e justificar tais situações à outra parte, indicando o prazo previsível para o restabelecimento da situação.
5. O ADJUDICATÁRIO deve, no prazo de 8 (oito) dias a contar do conhecimento da ocorrência, por correio eletrónico, fax ou por carta registada com aviso de receção, notificar a ENTIDADE ADJUDICANTE da duração previsível do acontecimento e dos seus efeitos na execução do CONTRATO, juntando certificado das entidades competentes que ateste a realidade e exatidão dos factos alegados e oferecendo prova de, em tempo devido, ter esgotado todos os meios para reduzir ao mínimo o atraso e os prejuízos na execução do CONTRATO.
6. Se o ADJUDICATÁRIO não puder, por razões que não lhe sejam imputáveis, apresentar os certificados referidos no número anterior dentro do prazo aí previsto, deve apresentá-los logo que possível, apresentando igualmente a justificação para tal atraso.
7. O incumprimento pelo ADJUDICATÁRIO do disposto nos números anteriores implica a sua responsabilidade pelo incumprimento das obrigações contratuais em causa, não podendo invocar os direitos previstos nos nºs 1 e 2.
Artigo 15.º Penalidades contratuais
1. Pelo incumprimento das datas e prazos de prestação do serviço objeto do contrato, o Contraente Público pode exigir ao Co-contratante o pagamento de uma pena pecuniária, nos seguintes termos:
a. Atraso de 12 horas no envio do relatório de exames não urgentes de doentes internados, conforme prazo estabelecido na proposta adjudicada, será penalizado em 50 % do valor do exame;
b. Atraso de um dia no envio do relatório de exames não urgentes, conforme prazo estabelecido na proposta adjudicada, será penalizado em 50 % do valor do exame;
c. Atraso de 60 minutos no envio do relatório de exames urgentes, conforme prazo estabelecido na proposta adjudicada, será penalizado em 60 % do valor do exame;
d. Não afetação do número de recursos humanos estabelecido na proposta adjudicada, será penalizado em 1.000,00 € por cada profissional a menos;
e. A realização de um relatório por um médico afeto ao HESE implica o não pagamento do mesmo;
f. A lentidão no envio de imagens será penalizada em 1.000,00 € por cada situação detetada e reportada;
g. Pelo incumprimento do prazo estipulado no ponto 8 do artigo 32.º do caderno de encargos será penalizado em 2.500,00 € por cada dia de atraso.
2. As penalidades serão descontadas na fatura do mês seguinte em que o Adjudicante teve conhecimento da infração.
3. As penas pecuniárias previstas na presente cláusula não obstam a que o Contraente Público exija uma indemnização pelo dano causado.
4. Aplicação das penas pecuniárias terão como limites máximos, os mencionados no artigo 329.º do CCP.
Artigo 16.º
Extinção ou suspensão do Contrato
1. Sem prejuízo do previsto no Código dos Contratos Públicos, no tocante à extinção do CONTRATO, a ENTIDADE ADJUDICANTE tem o direito de extinção do CONTRATO, sem que o ADJUDICATÁRIO tenha direito a qualquer indemnização, no seguinte caso:
a. Se o ADJUDICATÁRIO não cumprir o PRAZO DE ENVIO do relatório estabelecido, sem prejuízo da aplicação das penalidades previstas neste caderno de encargos ou no CONTRATO;
b. Se se verificar grave ou por mais de uma vez inobservância das disposições do CONTRATO ou quaisquer circunstâncias que revelem a existência de má fé por parte do ADJUDICATÁRIO.
2. A ENTIDADE ADJUDICANTE deve notificar o ADJUDICATÁRIO da decisão de extinção do CONTRATO por carta registada, com aviso de receção.
3. A execução das prestações que constituem o objeto do contrato pode ser, total ou parcialmente, suspensa de acordo com o disposto no artigo 297.º do Código dos Contratos Públicos.
4. Em caso de suspensão do contrato, o recomeço da execução, será efetuada nos termos do artigo 298.º do Código dos Contratos Públicos.
5. Em caso de resolução ou suspensão do CONTRATO, por qualquer título, o ADJUDICATÁRIO é obrigado a entregar de imediato toda a documentação e informação, independentemente da forma que esta revista, produzida no âmbito do CONTRATO e que esteja em sua posse, a qual é, para todos os efeitos, propriedade exclusiva da ENTIDADE ADJUDICANTE.
6. O ADJUDICATÁRIO pode extinguir o CONTRATO por incumprimento grave e reiterado das obrigações contratuais por parte da ENTIDADE ADJUDICANTE, desde que tal incumprimento seja a esta imputável, devendo notificar previamente a ENTIDADE ADJUDICANTE do motivo da extinção, e dando-lhe um prazo não inferior a sessenta dias para sanar tal incumprimento.
Artigo 17.º
Resolução do Contrato pelo Co-Contratante
1. O Co-contratante pode resolver o contrato nos termos do artigo 332.º do CCP.
2. A resolução do contrato no termo do número anterior não determina a repetição das prestações já realizadas pelo Co-contratante, cessando, porém, todas as obrigações deste ao abrigo do contrato, com exceção daquelas a que se refere o artigo 444.º do CCP.
Artigo 18.º
Suspensão da Execução do Contrato
1. A execução das prestações que constituem o objeto do contrato pode ser, total ou parcialmente, suspensa de acordo com o disposto no artigo 297.º do CCP.
2. Em caso de suspensão do contrato, o recomeço da execução, será efetuada nos termos do artigo 298.º do CCP.
Artigo 19.º
Conflito de interesses e imparcialidade
1. O ADJUDICATÁRIO deve prosseguir a sua atividade de acordo com a lei aplicável e com as regras de boa fé, tomando todas as medidas necessárias para evitar a ocorrência de quaisquer situações que possam resultar em conflito com os interesses da ENTIDADE ADJUDICANTE.
2. O ADJUDICATÁRIO obriga-se a não praticar qualquer ato ou omissão do qual possa resultar quaisquer ónus ou responsabilidades para a ENTIDADE ADJUDICANTE ou para os seus direitos e interesses.
Artigo 20.º Confidencialidade
1. Sem prejuízo do disposto no número seguinte, as partes comprometem-se a não divulgar, durante e após a execução do CONTRATO, quaisquer informações que obtenham no seu âmbito, designadamente as relativas à outra parte ou aos seus interesses e negócios.
2. As partes só podem divulgar informações referidas no número anterior na medida em que tal seja estritamente necessário à execução do CONTRATO, mediante autorização da parte que as haja prestado, ou do estritamente necessário ao exercício do direito de defesa em processo contencioso.
3. No caso previsto no número anterior, as partes devem garantir, em reciprocidade e em condições satisfatórias, a assunção, por escrito, de idêntico compromisso de confidencialidade pelos terceiros que acedam às informações abrangidas pelo dever de confidencialidade.
4. As partes devem ainda limitar o acesso às informações confidenciais aos seus quadros e funcionários que a elas tenham de recorrer para a correta execução do CONTRATO, assegurando que os mesmos são obrigados a manter essa confidencialidade.
5. São suscetíveis de serem consideradas informações confidenciais, sem prejuízo de outras que as partes decidam qualificar como tal, as que, a serem divulgadas, possam causar danos a qualquer das partes ou a terceiros, ou perturbar o normal desenvolvimento dos trabalhos da prestação de serviços objeto deste caderno de encargos.
Artigo 21.º Propriedade intelectual e industrial
1. A ENTIDADE ADJUDICANTE tem o direito exclusivo de divulgar ou publicar todos os documentos elaborados no âmbito da prestação de serviços objeto deste caderno de encargos, em todo o mundo, por um prazo de 10 anos, seja em formato papel, ou em formato eletrónico, junto dos seus clientes, parceiros, autoridades ou público em geral, não importando tal circunstância o pagamento de qualquer outra quantia, além daquele paga no ato de entrega do documento.
2. A ENTIDADE ADJUDICANTE pode utilizar apenas excertos dos documentos, cabendo-lhe, em exclusivo, a sua definição.
3. A ENTIDADE ADJUDICANTE reserva-se o direito de mandar elaborar traduções destes documentos, nas línguas que escolher, podendo utilizar tais traduções nos termos definidos no n.º 1.
4. São da responsabilidade do ADJUDICATÁRIO quaisquer encargos decorrentes da utilização, na presente prestação de serviços, de patentes, licenças, marcas, desenhos registados e outros direitos de propriedade industrial ou direitos de autor ou conexos.
5. Se, por algum motivo, a ENTIDADE ADJUDICANTE vier a ser demandada por ter infringido, na execução do CONTRATO, ou deste decorrente, qualquer dos direitos mencionados no número anterior, a ENTIDADE ADJUDICANTE terá direito de regresso, contra o ADJUDICATÁRIO, por quaisquer quantias pagas, seja a que título for.
Artigo 22.º
Execução e Liberação da Caução
1. A caução prestada para bom e pontual cumprimento das obrigações decorrentes do contrato, nos termos do Programa do Procedimento, pode ser executada pelo Contraente Público, sem necessidade de prévia decisão judicial ou arbitral, para satisfação de quaisquer importâncias resultantes de mora, cumprimento defeituoso, incumprimento definitivo pelo Co-contratante das obrigações contratuais ou legais, incluindo o pagamento de penalidades, ou para quaisquer outros efeitos especificamente previstos no contrato ou na lei.
2. A resolução do contrato pelo Contraente Público não impede a execução da caução, desde que para isso haja motivo.
3. A execução parcial ou total da caução referida nos números anteriores constitui o Co- contratante na obrigação de proceder à sua reposição pelo valor existente antes dessa mesma execução, no prazo de 15 (quinze) dias após a notificação do Contraente Público para esse efeito.
4. Quando não haja a renovação da caução nos termos do número anterior, pode o Contratante Público resolver o contrato a título sancionatório, nos termos da alínea g) do n.º 1 do artigo 333.º do CCP.
5. A caução prestada pelo concorrente a quem venha a ser adjudicado o objecto do contrato responderá pelo cumprimento pontual das obrigações que o Co-contratante assume, sem prejuízo das indemnizações legais que o Estado venha a ter direito pelos prejuízos que daí lhe advenham.
6. A caução prestada pelo ADJUDICATÁRIO será libertada pela ENTIDADE ADJUDICANTE, de acordo com o disposto no artigo 295.º do Código dos Contratos Públicos.
Artigo 23.º Notificações e comunicações
1. Quaisquer notificações e comunicações a efetuar entre as partes, nos termos do CONTRATO ou da lei aplicável, devem ser escritos e redigidos em português e efetuados através de correio eletrónico, fax ou correio registado com aviso de receção, devendo ser endereçadas para as moradas indicadas no CONTRATO e presumindo-se efetuadas nas seguintes condições:
Transmissão | Data de efetividade |
Correio electrónico | Na data de respetiva expedição |
Fax | Na data constante do relatório de transmissão |
Xxxxxxx registado com aviso de receção | Na data da assinatura do aviso |
2. As notificações e as comunicações que tenham como destinatário a ENTIDADE ADJUDICANTE e que sejam efetuadas através de correio eletrónico ou fax, após as 17 horas do local de receção ou em dia não útil nesse mesmo local, presumem-se feitos às 10 horas do dia útil seguinte.
3. Qualquer das partes pode, em qualquer momento, comunicar à outra a mudança de algum dos endereços ou contactos indicados no CONTRATO.
Artigo 24.º Gestor do Contrato
O Contraente Público deve designar um gestor do contrato, com a função de acompanhar permanentemente a execução deste, conforme o artigo 290.º-A do CCP.
Artigo 25.º Outros Encargos
Todas as despesas derivadas da elaboração da proposta, nomeadamente as despesas e encargos inerentes à prestação do contrato.
Artigo 26.º
Direitos de Propriedade Intelectual e Industrial
1. São inteiramente da responsabilidade do Co-contratante os encargos ou a responsabilidade civil decorrentes da incorporação em qualquer dos bens objeto do contrato, ou da utilização nesses mesmos bens, de elementos de construção, de hardware, de software ou de outros que respeitem a quaisquer patentes, licenças, marcas, desenhos registados e outros direitos de propriedade industrial ou direitos de autor ou conexos.
2. Se o Contraente Público vier a ser demandado por ter infringido, na execução do contrato ou na posterior utilização dos bens objeto do mesmo, qualquer dos direitos referidos no número anterior, terá direito de regresso contra o Co-contratante por quaisquer quantias pagas, seja a que título for.
Artigo 27.º Contagem dos Prazos
Os prazos previstos no contrato são contínuos, correndo em sábados, domingos e dias feriados, nos termos da alínea b) do n.º 1 do artigo 471.º do CCP.
Artigo 28.º Execução do Contrato
O Contraente Público e o Co-contratante encontram-se obrigados a atuar de boa-fé durante a execução do contrato e a não exercer os direitos nele previstos, ou na lei, de forma abusiva.
Artigo 29.º Legislação Aplicável
1. O contrato fica sujeito ao disposto na legislação portuguesa, com renúncia expressa a qualquer outra.
2. Sem prejuízo de outras leis e regulamentos especialmente aplicáveis, a tudo o que não esteja expressamente previsto ou regulado no presente caderno de encargos e na demais regulamentação do contrato aplica-se o regime previsto no Código dos Contratos Públicos aprovado pelo decreto-lei n.º111-B/2017 de 31 de agosto e respetivas alterações.
Artigo 30.º Foro competente
1. Na eventualidade de qualquer conflito, as partes devem sempre procurar chegar a um acordo sobre a situação em litígio, dentro dos princípios da boa fé contratual, antes de recorrer a meios contenciosos.
2. No caso de as partes não conseguirem chegar a um acordo, nos termos do número anterior, deve o litígio ser dirimido de acordo com a legislação portuguesa aplicável e é competente o Tribunal Administrativo e Fiscal de Beja, com expressa renúncia a qualquer outro.
PARTE II CLÁUSULAS TÉCNICAS
Artigo 31.º Especificações Técnicas
1. Os serviços objeto do presente convite, Prestação de Serviços no âmbito da Telemedicina nas áreas de TAC e RM, serão prestados nas instalações do adjudicatário.
2. Prestação de Serviços:
a. COBERTURA 24 HORAS/DIA, TODOS OS DIAS DO ANO;
b. Envio de imagens médicas obrigatoriamente através da RIS (Rede Informática da Saúde).
c. O Envio de imagens deverá ser feito de forma automática por interface entre o PACS existente no HESE e os servidores de destino. Não deverá haver qualquer intervenção manual em plataforma externa ao sistema do hospital.
d. O envio de pedido de relatório terá também de ser efetuado de forma automática exatamente nas mesmas condições expressas no artigo anterior.
e. Apesar do automatismo descrito nas alíneas anteriores, deverá ser possível efetuar inserção manual de pedido de relatório e envio de imagens. Esta solução servirá para utilização em caso de falha do RIS/PACS existente no HESE;
3. Modo de Entrega dos Exames e dos Relatórios:
a. Deverá ser disponibilizado o relatório em formato digital, integrados no PACS/RIS existente no HESE e compatibilidade DICOM (Consultar Anexo IV).
b. Os relatórios terão de ser disponibilizados de três formas diferentes:
i. Através de plataforma disponibilizada pelo concorrente para o efeito;
ii. No RIS – Sistema de Informação para Imagiologia existente no hospital;
iii. No visualizador de imagens e relatórios existente no hospital
4. Prazos máximos de resposta:
a. Os prazos máximos de resposta serão os seguintes:
i. VIA VERDE – RESPOSTA IMEDIATA
ii. Exames Urgentes: 80 minutos;
iii. Exames não urgentes - doentes internados: 7 horas;
iv. Exames não urgentes: 72 horas.
5. Produção adicional:
a. Caso o HESE realize exames em modalidade de produção adicional (fim de semana e feriados), independentemente da hora em que são realizados/enviados, o valor a considerar para efeitos de pagamento será o preço mais baixo para a tipologia de exame;
b. Para efeitos de identificação dos exames, referidos no ponto anterior, o HESE mencionará “Exames de Consulta programada” aquando o envio do exame;
6. Instalações e Equipamentos:
a. As imagens enviadas por telerradiologia têm origem em sistemas PACS;
b. Todos os sistemas devem ter um mecanismo de verificação de integridade que assegure que todos os dados transmitidos pelo local de origem são recebidos intactos no local de destino;
c. O sistema deve ser garantidamente seguro mantendo a confidencialidade do doente;
d. O prestador deve assegurar que a qualidade da imagem é a mesma no local de aquisição e no local de interpretação;
e. As estações de trabalho utilizadas em telerradiologia ou PACS devem ter as seguintes características de Luminância da escala de cinzentos de pelo menos 50 foot-lamberts e os monitores devem reproduzir fielmente o estudo original e incluir:
i. Funções de brilho e contraste ou janela e nível;
ii. Funções de aumento;
iii. Capacidade para rodar e inverter a imagem;
iv. Capacidade para medidas lineares e de unidades Hounsfield;
v. Capacidade para inverter a escala de cinzentos;
vi. Capacidade para mostrar os parâmetros clínicos relevantes.
f. A prestação de serviços será realizada nas instalações do Co-Contratante;
g. As instalações do Co-contratante deverá ser possuidora de certificação, nomeadamente pela Entidade Reguladora da Saúde (ERS);
h. O Co-contratante deverá ser possuidor de equipamento necessário para a realização da prestação de serviços e responsável pela manutenção e reparação/substituição de equipamento sempre que o considere necessário, sem custos para o Contraente Público.
7. Condições Técnicas:
O software/plataforma de telemedicina deverá garantir:
a. Integração HL7 de relatórios no RIS do HESE - O RIS/PACS implementado no HESE – EPE é uma solução da SIEMENS com as seguintes versões:
b. PACS – Syngo Share e Syngo Plaza
c. RIS – Xxxxx Xxxxxxxx XX 00
d. Integração de todos os pedidos de exames para o exterior para que os pedidos sejam enviados automaticamente do RIS existente no HESE para a plataforma de destino sem intervenção manual do hospital, existindo no entanto possibilidade de inserção manual no caso do sistema RIS/PACS existente no HESE estar em baixo;
e. Integração de exames no PACS do HESE (Dicom Store, Dicom Query);
f. Ícone no RIS de envio de exame e de relatório associado;
g. Deverá assegurar a extração/consulta de:
h. Exames relatados (validados);
i. Exames por relatar (por validar);
j. Exames por médico relator (listagens sempre entre datas).
k. Deverá ser permitida a inserção de pedido de relato de exames manualmente, em caso de falha da comunicação RIS -> Plataforma Telemedicina;
l. Deverá garantir a permanência de todos os exames (imagens) e relatórios de todos os exames que ao longo do tempo forem relatados nesta plataforma;
m. Deverá permitir a visualização direta dos relatórios na plataforma;
n. Critérios de pesquisa e alertas – Alerta quando algum relatório é concluído;
o. Criação de um circuito de backup para envio de imagens quando a Rede Informática da Saúde estiver indisponível.
p. Possibilidade de enviar mais do que 1 exame de cada vez, com garantia de que o tempo de envio não é comprometido e garantindo os tempos contratados;
q. O Sistema deverá ter a capacidade de pausar um exame que está a ser enviado sempre que entre um exame com prioridade máxima (Via Verde ou Urgência). Este procedimento deverá acontecer de forma automatizada. O exame ou exames que estavam a ser enviados deverão ser retomados também de forma automática assim que terminar o envio dos exames prioritários. Deverá ainda ser garantida a possibilidade de efetuar este processo manualmente caso o operador assim o entenda.
r. O Sistema deverá ter a capacidade de pausar um exame que está a ser enviado sempre que entre um exame com prioridade máxima (Via Verde ou Urgência). Este procedimento deverá acontecer de forma automatizada. O exame ou exames que estavam a ser enviados deverão ser retomados também de forma automática assim que terminar o envio dos exames prioritários. Deverá ainda ser garantida a possibilidade de efetuar este processo manualmente caso o operador assim o entenda.
s. O tempo máximo de envio de um exame não deverá ser superior a 30 minutos.
8. Corpo Clinico:
a. Os médicos propostos para a prestação devem estar inscritos no Colégio de Radiologia e/ou no Colégio de Neurorradiologia da Ordem dos Médicos e possuir certificação específica para a valência dos exames em causa;
b. A interpretação das imagens deve ser feita por um especialista com conhecimento da tecnologia envolvida na Telerradiologia;
c. O médico especialista responsável pelo exame tem de assegurar que as imagens que interpreta têm qualidade aceitável;
d. O Co-contratante deverá ter no seu corpo clínico, o seguinte número mínimo de médicos especialistas em cada uma das áreas:
i. 2 Médicos Radiologista;
ii. 2 Médicos de Neurorradiologia.
9. O prazo para início da prestação de serviços, após outorga do contrato, não poderá ser superior a 15 dias seguidos;
10.O não cumprimento das especificações técnicas enunciadas nos números anteriores é motivo de exclusão da proposta.
Artigo 33.º Outras Obrigações
1. O Corpo Clínico apresentado pelo Co-contratante deverá ter presente, e sem prejuízo com o disposto da lei, o Regulamento n.º 14/2009 de 13 de janeiro, referente ao Código Deontológico.
2. Cumprimento da Portaria n.º 35/2014, de 12 de fevereiro, referente aos requisitos mínimos relativos à organização e funcionamento, recursos humanos e instalações técnicas das unidades de saúde de Radiologia.
3. O Co-contratante deve “contratar e manter em vigor um seguro de responsabilidade civil que cubra os riscos inerentes à respectiva actividade e exigir dos seus profissionais seguro de responsabilidade profissional válido”, nos termos do artigo 7.º da Portaria n.º 35/2014, de 12 de fevereiro.
a. O Contraente Público pode sempre que entender necessário, exigir ao Co-Contratante os documento que comprovem a celebração dos contratos de seguros, referidos no n.º 3, devendo ser entregues no prazo de 10 (dez) dias.
4. Durante a execução do Contrato o Co-contratante fica obrigado a informar o Contraente Público sempre que haja alteração do corpo clinico, definido na proposta adjudicada. Posto isto, o Co- contratante tem 10 (dez) dias corridos para apresentar junto do Contraente Público, através do email xxxxxxxxx.xxxxx@xxxxxx.xxx-xxxxx.xx , a documentação do novo médico para a realização de exames, nomeadamente, a cópia do Cartão da Ordem comprovando ser detentor da especialidade, nos termos do n.º 8 do artigo 24.º das Clausulas Técnicas.
5. Como o Co-contratante irá praticar um serviço público, fica também sujeito às normas e princípios comunitários aplicáveis ao Contraente Público.
Artigo 34.º Formação
O Co-contratante é responsável financeiramente por toda e qualquer formação dos profissionais de saúde e aos demais colaboradores a si afetos, tendo como fim a correcta execução da prestação de serviços objecto do contrato.
Anexo I - Lista de Quantidades
Proposta | |||||
Variáveis de Custo | Preço base por variável de Custo Preço por variável de (PVC) Custo (PVC) 19,00 € | Preço Total (PT) | |||
Tipo de Exame Prioridade N.º de Exames a Realizar (NE) | |||||
TAC | Normal | 9274 | 176.206,00 € | ||
Urgente I | 5614 | 21,00 € | 117.894,00 € | ||
Urgente II | 2862 | 28,00 € | 80.136,00 € | ||
RM | Normal | 2096 | 25,00 € | 52.400,00 € | |
Urgente I | 78 | 30,00 € | 2.340,00 € | ||
Urgente II | 10 | 35,00 € | 350,00 € | ||
TOTAL | 429.326,00 € | ||||
Legenda:
− Qtd: Quantidade previstas para 12 meses.
− Preço base: Propostas com preços superiores ao preço base serão excluídas
Anexo II – Modelo de declaração
(substitui o Anexo I ao CCP em caso de CP com publicação no JOUE)
(nome, número de documento de identificação e morada), na qualidade de representante legal de (1) (firma, número de identificação fiscal e sede ou, no caso de agrupamento concorrente, firmas, números de identificação fiscal e sedes), tendo tomado inteiro e perfeito conhecimento do caderno de encargos relativo à execução do contrato a celebrar na sequência do procedimento de
(designação ou referência ao procedimento em causa) e, se for o caso, do caderno de encargos do acordo-quadro aplicável ao procedimento, declara, sob compromisso de honra, que a sua representada (2) se obriga a executar o referido contrato em conformidade com o conteúdo do(s) mencionado(s) no presente caderno(s) de encargos, relativamente ao qual declara aceitar, sem reservas, todas as suas cláusulas, no valor de (3) , conforme nossa proposta.
(local) , (data) . (assinatura)
Anexo III – Modelo de Declaração
adjudicatário(a) no procedimento de“………………..” (designação ou referência ao procedimento em causa), declara, sob compromisso de honra, que a sua representada (2) não se encontra em nenhuma das situações previstas no n.º 1 do artigo 55.º do Código dos Contratos Públicos:
2 - O declarante junta em anexo os documentos comprovativos de que a sua representada (4) não se encontra nas situações previstas nas alíneas b), d), e) e i) do n.º 1 do artigo 55.º do Código dos Contratos Públicos.
3 - O declarante tem pleno conhecimento de que a prestação de falsas declarações implica a caducidade da adjudicação e constitui contraordenação muito grave, nos termos do artigo 456.º do Código dos Contratos Públicos, a qual pode determinar a aplicação da sanção acessória de privação do direito de participar, como candidato, como concorrente ou como membro de agrupamento candidato ou concorrente, em qualquer procedimento adotado para a formação de contratos públicos, sem prejuízo da participação à entidade competente para efeitos de procedimento criminal.
Anexo IV – Modelo de Garantia Bancária “Garantia Bancária”
Ao Hospital do Espirito Santo de Évora, E.P.E.
Xxxxx Xxxxxx xx Xxxxxxx, 0000-000 Xxxxx
O (Banco), com sede em (morada) vem prestar, por conta e a pedido de
(nome do adjudicatário), com sede em (morada), como adjudicatário do procedimento n.º xxxx/xxx, relativo ao concurso que tem como objecto a “ ”, garantia bancária até ao valor de Euros (repetir por extenso) em caução do bom e pontual cumprimento por aquele das obrigações decorrentes das peças procedimentais.
Consequentemente, este Banco constitui-se devedor e principal pagador em dinheiro, ao Hospital do Espirito Santo de Évora, E.P.E., até àquele valor sem quaisquer reservas, e para todos os efeitos legais, de todas e quaisquer importâncias que lhe venham a ser solicitadas por escrito pelo beneficiário, à primeira solicitação e até um limite máximo de 48 horas, sem questionar da sua justeza ou conformidade com o disposto no processo de concurso e documentos a ele anexos.
Esta garantia é de (por algarismos e por extenso) e só será cancelada quando o beneficiário nos comunicar por escrito que cessaram todas as obrigações do caucionado, decorrentes do acima especificado, o que deverá ser feito de acordo com o estabelecido nas peças do procedimento.
[Data e assinatura do(s) representante(s) legal(ais)]
Anexo V – Modelo de Seguro-Caução
A (companhia de seguros), com sede em (morada) presta a favor do Hospital do Espírito Santo de Évora, E.P.E., e ao abrigo de contrato de seguro-caução celebrado com (tomador de seguro), garantia à primeira solicitação no valor de destinada a garantir o bom e integral cumprimento das obrigações que (adjudicatário), com sede (morada), assumirá no contrato que com ela ao Hospital do Espírito Santo de Évora, E.P.E., vai outorgar e que tem por objecto a “ ” referente ao procedimento n.º xxxx/xx, regulada nos termos da legislação portuguesa aplicável.
A companhia de seguros obriga-se a pagar aquela quantia nos cinco dias úteis seguintes à primeira solicitação do Hospital do Espírito Santo de Évora, E.P.E., sem que estes tenham de justificar o pedido e sem que a primeira pessoa possa invocar em seu benefício quaisquer meios de defesa relacionados com o contrato atrás identificado ou com o cumprimento das obrigações que
(adjudicatário) assume com a celebração do respetivo contrato.
A companhia de seguros não pode opor ao Hospital do Espírito Santo de Évora, E.P.E., quaisquer exceções relativas ao contrato de seguro-caução celebrado entre estes e o tomador do seguro.
A presente garantia, à primeira solicitação, não pode em qualquer circunstância ser revogada ou denunciada, mantendo- se em vigor até à sua extinção ou cancelamento, nos termos previsto no contrato e na legislação aplicável.
[Data e assinatura do(s) representante(s) legal(ais)]
Anexo VI - Modelo de Guia de Depósito
Vai (nome do Adjudicatário), com sede em , pessoa coletiva n.º , matriculada na Conservatória do Registo Comercial de sob o n.º , com o capital social de , representado(a) pelos Senhores
e , na qualidade respetivamente de e
, depositar na (sede, filial, agência ou delegação) da (instituição), a quantia de Euros ( euros), (em dinheiro), como caução exigida para a prestação de serviços de
, para os efeitos do disposto no n.º 1 do artigo 88.º do Código dos Contratos Públicos. Este depósito fica à ordem do Hospital do Espírito Santo de Évora, E.P.E., a quem deve ser remetido o respetivo conhecimento.
[Data e assinatura do(s) representante(s) legal(ais)]
Anexo VII – DICOM Conformance Statement
Distributed by:
s
DICOM 3.0 Conformance Statement
syngo.share / Release VA23B / 2016-03-14
About This Document
Target Group
This document is intended for personnel working in health care information technology, including project managers, solution consultants, and developers. Further, the terms used in this document are defined according to the DICOM Standard. Therefore, we assume that the user is familiar with the terminology and concepts that are used in the DICOM 3.0 Standard.
Purpose
This document describes syngo.share’s compliance with the Digital Imaging and Communications in Medicine (DICOM) Standard 3.0.
This document was typeset with X LATEX
Table of Contents
1 Introduction 5
1.1 Remarks 5
2 Implementation Model 6
2.1 Application Data Flow Diagram 6
2.1.1 syngo.share view Data Flow Diagram 6
2.1.2 syngo.share import Data Flow Diagram 6
2.1.3 webadmin Data Flow Diagram 7
2.1.4 DicomServer Data Flow Diagram 7
2.1.5 EventServer Data Flow Diagram 7
2.2 Functional Definition of AEs 8
2.2.3 webadmin 8
2.2.4 DicomServer 10
2.2.5 EventServer 11
2.3 Sequencing of Real-World Activities 11
3 Application Entity Specifications 12
3.1.1 Supported SOP Classes for syngo.share view-ID AE 12
3.1.2 Association Establishment Policies 12
3.1.2.1 General 12
3.1.2.2 Number of Associations 12
3.1.2.3 Asynchronous Nature 12
3.1.2.4 Implementation Identifying Information 13
3.1.2.5 Association Initiation Policy by Real-World Activity 13
3.3 webadmin 13
3.4 DicomServer 13
3.4.1 Supported SOP Classes and Transfer Syntaxes 13
3.4.2 Association Establishment Policies 18
3.4.2.1 General 18
3.4.2.2 Number of Associations 19
3.4.2.3 Asynchronous Nature 19
3.4.2.4 Implementation Identifying Information 19
3.4.2.5 Extended Negotiation 19
3.4.3 Association Initiation Policy by Real-World Activity 19
3.4.3.1 Real-World Activity: C-MOVE Request 19
3.4.3.2 Real-World Activity: C-FIND Spanning 19
3.4.3.3 Real-World Activity: C-MOVE Spanning 20
3.4.4 Association Acceptance Policies 20
3.4.4.1 Real-World Activity: Storage SCU 20
3.4.4.2 KOS - Rejection Notes 20
3.5 EventServer 21
3.5.1 Supported SOP Classes 21
3.5.2 Association Establishment Policies 21
3.5.2.1 General 21
3.5.2.2 Number of Associations 21
3.5.2.3 Asynchronous Nature 21
3.5.2.4 Implementation Identifying Information 21
3.5.2.5 Association Initiation Policy by Real-World Activity 21
4 DICOM Media AE Specification 22
4.1 Implementation Model 22
4.1.1 Application Data Flow Diagram 22
4.1.2 Functional Definitions of AEs 22
4.1.3 Sequencing of Real World Activities 22
4.1.4 File Meta Information 22
4.2 Application Entity Specification 22
4.2.1 view 22
4.2.1.1 Real World Activities 23
4.2.2.1 Real World Activities 23
4.2.3 webadmin 23
4.2.3.1 Real World Activities 24
4.3 Augmented and Private Application Profiles 24
5 Communication Profiles 25
5.1 Supported Communication Stacks 25
6 Security Profiles 26
6.1 Audit Trail Message Format Profile 26
7 Configuration 29
8 Support of Extended Character Sets 30
8.1 Supported Character Sets 30
8.2 Configuration capabilities 30
8.3 Query capabilities 30
A Key list for Query/Retrieve-Service classes 32
A.1 Keys for C-FIND requests on Patient Level 32
A.2 Keys for C-FIND requests on Study Level 32
A.3 Keys for C-FIND requests on Series Level 32
A.4 Keys for C-FIND requests on Image Level 33
A.5 Keys for C-FIND requests issued by view on Study Level 35
B Key list for Modality Worklist C-FIND requests 36
List of Figures
1 syngo.share view FSC and syngo.share view FSR Application Data Flow Diagram 6
2 syngo.share view ID AE Application Data Flow Diagram 7
3 syngo.share import Data Flow Diagram 7
4 webadmin Data Flow Diagram 8
5 DicomServer Data Flow Diagram 9
6 EventServer Data Flow Diagram 10
List of Tables
1 Supported Query/Retrieve SOP classes 12
2 Supported Print Management SOP classes 12
3 Implementation Details 13
4 Supported view C-MOVE Transfer Syntaxes 13
6 Supported Storage SOP classes 17
7 Supported Private Storage SOP classes 17
8 Supported Query/Retrieve SOP classes 17
9 Supported Verification SOP classes 18
10 Supported Storage Commitment SOP classes 18
11 Supported Modality Performed Procedure Step SOP classes 18
12 Supported Storage Transfer Syntaxes 18
13 Implementation Details 19
14 Supported Instance Availability Notification SOP classes 21
15 Implementation Details 21
16 Implementation Details 22
17 Supported Character Sets 31
1 Introduction
This document is a DICOM 3.0 Conformance Statement that describes the DICOM capabilities for the following five products and components of syngo.share:
DicomServer EventServer syngo.share view syngo.share import webadmin
DicomServer is the central module for medical data processing in syngo.share. As hospital-wide solution for PACS, image and document management, syngo.share collects all image data and documents within your hospital processing them into the multimedia electronic patient record.
EventServer is able to generate DICOM Instance Availability Notifications (IANs for short), based on inter- nal events or incoming DICOM MPPS requests, and sends them to one or more AEs.
syngo.share view is a versatile multi-modality displaying system for DICOM images. It is able to retrieve and display DICOM images either from specified directories or CD media or from syngo.share archive or with Query/Retrieve from third party PACS systems. Additionally syngo.share view supports printing and exporting DICOM images, series or studies on CD media.
syngo.share import is able to load DICOM images, series and studies from specified directories or CD media and import them into syngo.share.
webadmin is a Web 2.0 portal which enclosures Internet-Browser-based solutions in syngo.share. It offers a possibility for downloading DICOM images from syngo.share and storing it on a specified directory. This happens by the so called Web Access to DICOM Persistent Objects (WADO), as specified in DICOM 2013 PS 3.18.
This Conformance Statement should help to validate the integration of DicomServer, EventServer, syngo.share view, syngo.share import, and webadmin within a DICOM environment. This statement is not intended to replace the validation with other DICOM equipment to ensure proper exchange of information intended. Thus, it is still important to ensure the proper interoperability of the intended DICOM integration.
The user should be aware of the following important issues:
The comparison of different Conformance Statements should be the first step towards the assess- ment of the interoperability within a DICOM environment
Test procedures should be defined to validate the desired level of connectivity.
2 Implementation Model
2.1 Application Data Flow Diagram
2.1.1 syngo.share view Data Flow Diagram
syngo.share view provides a user interface for reading (i.e. FSR) and exporting (i.e., FSC) DICOM files from portable media (e.g. CDs), network directories or the local file system. These functions are integral com- ponents of syngo.share view. However, within the context of this Conformance Statement the reading functionality is referred to as syngo.share view-FSR Application Entity (AE) and the exporting functionality as syngo.share view-FSC AE.
Export DICOM file set
Read DICOM file set
Remote Real World Activity
FSC
FSR
DICOM
Storage Media
view (Export-/Import
Module)
Figure 1: syngo.share view FSC and syngo.share view FSR Application Data Flow Diagram
Additionally syngo.share view provides the ability to query third party PACS systems and retrieve data from them. syngo.share view also provides report reading capabilities for Structured Reports and the possibility to apply Grayscale Softcopy Presentation States (GSPS) as defined in DICOM 2013 PS 3.3. For display consistency the DICOM Grayscale Standard Display Function (GSDF) as described in DICOM 2013 PS 3.14 is supported. In this Conformance Statement the capabilities of syngo.share view as an image display are referred to as syngo.share view-ID AE.
2.1.2 syngo.share import Data Flow Diagram
syngo.share import is able to read (i.e. FSR) DICOM files from portable media (e.g. CDs), network direc- tories or the local file system. Loaded DICOM file sets can be imported directly into syngo.share. Within the context of this Conformance Statement the importing functionality of syngo.share import is referred to as syngo.share import-FSR AE.
2.1.3 webadmin Data Flow Diagram
webadmin offers download possibilities for DICOM images from syngo.share by using WADO requests. The downloaded files can be stored anywhere on a portable media (e.g. CDs), network directory or the local file system.
2.1.4 DicomServer Data Flow Diagram
DicomServer is implemented as a single AE which provides a set of different services. For each of these services DicomServer can act in a specific role.
By default the different services are accessible through one predefined AE title of an actual DicomServer
instance.
2.1.5 EventServer Data Flow Diagram
EventServer is able to generate DICOM IANs, based on internal events or incoming DICOM MPPS requests, and sends them to one or more AEs. In order to fulfill this task it supports the following services.
Local Application Entities
Remote Real World Activity
view ID AE
Query/Retrieve data from third party system
Query/Retrieve SCP
Query/Retrieve SCU
DICOM Standard Interface
Figure 2: syngo.share view ID AE Application Data Flow Diagram
Remote Real World Activity
Media Import
FSR
DICOM
Storage Media
import (Import Module)
Implementation Model
Figure 3: syngo.share import Data Flow Diagram
2.2 Functional Definition of AEs
The syngo.share view-FSR AE is able to read and syngo.share view-FSC AE is able to write user-selected DICOM files like DICOMDIR or image objects which are compliant to DICOM 2013 PS 3.10. These files can be located either on the local file system or DICOM 2013 PS 3.12 compliant media. Both AEs support the General Purpose CD-R Interchange Profile.
The syngo.share view-FSC AE allows the usage of any other third party CD editing software which can write directory structures to CDs. Thus, the syngo.share view-FSC AE basically is able to write DICOM file sets also to DVD-RAM.
The syngo.share view-ID AE is able to query third party PACS systems using the C-FIND Service and retrieve data using the C-MOVE Service according to DICOM 2013 PS 3.7. The third party PACS systems can be queried using the Study Root Query/Retrieve Information Model as defined in DICOM 2013 PS 3.4, C.3.2. For C-FIND SCU and C-MOVE SCU baseline behavior is supported.
The syngo.share view-ID AE is able to render images and structured reports received using Query/Retrieve or syngo.share view-FSR AE. All three general structured report document classes are supported. They are specified in DICOM 2013 PS 3.3. The contents are rendered as text with references to other instances. Referenced images can be shown and referenced GSPS can be applied. All spatial transformations, pre- sentation LUTs and textual annotations are supported. Section 3.1 describes the supported SOP Classes for syngo.share view-ID.
The syngo.share import-FSR AE is able to read user-selected DICOM files like DICOMDIR or image objects which are compliant to DICOM 2013 PS 3.10. These files can be located either on the local file system or DICOM 2013 PS 3.12 compliant media.
The webadmin AE waits for a WADO request from another application (e.g. an Internet Browser). If this happens, webadmin queries syngo.share for the requested DICOM image and returns it to the requesting
Local Application Entities
Remote Real World Activity
WADO
request
Query/ Retrieve SCU
webadmin (Import Module)
Implementation Model
DICOM Standard Interface
Figure 4: webadmin Data Flow Diagram
application.
Import into system
Local Application Entities
Storage SCP
DicomServer AE
Remote Real World Activity
Storage SCU
Storage SCU
Storage SCP
Retrieve Data from system
Query/ Retrieve SCU
Query/Retrieve SCP
Local database processes query
Modality Worklist SCP
Modality Worklist Query
Verification SCP
Verification Request
Storage Commitment
SCP
Storage Commitment Request
Modality Performed Procedure Step
SCU/SCP
MPPS SCP
Implementation Model
MPPS SCU
DICOM
Standard Interface
Figure 5: DicomServer Data Flow Diagram
DicomServer AE waits for another application to connect and initiate a DICOM association. When another application connects, DicomServer AE expects it to be a DICOM application. DicomServer AE implements several DICOM Service Classes. In total the following services are provided by this AE:
Verification SCP answers communication tests from remote applications – C-ECHO
Storage SCP implements the answer to external C-STORE requests. It is able to receive incoming DICOM image files sent by remote DICOM applications (e.g., modalities or workstations) and add them to syngo.share database.
The Query/Retrieve SCP implements the answer to C-FIND, C-MOVE and C-GET requests. Remote applications can request queries on Patient-, Study-, Series- or Image-level using the Patient Root or Study Root query model. DicomServer AE functions as a Storage SCU when responding to a C-MOVE request.
C-FIND Spanning forwards incoming C-FIND requests unaltered to an arbitrary number of config- ured Query/Retrieve SCP targets and returns their results.
C-MOVE Spanning forwards incoming C-MOVE requests to an arbitrary number of Query/Retrieve SCP targets.
Modality Worklist SCP allows remote applications (e.g., modalities) to query the syngo.share database for modality worklists.
Storage Commitment SCP implements the answer to external N-ACTION requests and sends back the N-EVENT-REPORT response. The response can be sent on either the incoming or on a newly established association.
Modality Performed Procedure Step SCU/SCP implements the answer to external N-CREATE/N-SET requests and forwards the received requests to all configured destinations. The forwarding can be disabled.
On association startup the calling AET is looked up in the database to determine a corresponding configu- ration. This configuration determines the DicomServer behavior in several aspects including the number of services provided and the data accessible to the requesting AE.
Local Application Entities
IAN SCP
Remote Real World Activity
Local database processes query
XXX XXX
Implementation Model
DICOM Standard Interface
Figure 6: EventServer Data Flow Diagram
EventServer AE generates DICOM IANs, based on internal events or incoming DICOM MPPS requests, and sends them to one or more AEs.
2.3 Sequencing of Real-World Activities
The services of syngo.share view- and syngo.share import-AEs can be requested at any time by the user through the user interface.
The services of webadmin AE can also be requested at any time by the user or the application that performs the WADO request.
The services of DicomServer AE must be requested according to the Service Class specifications in DICOM 2013 PS 3.3.
Implementation Model
The services of EventServer AE are triggered automatically.
3 Application Entity Specifications
syngo.share view-FSC and syngo.share view-FSR, solely provide functionalities for handling DICOM media.
3.1.1 Supported SOP Classes for syngo.share view-ID AE
The syngo.share view-ID AE provides standard conformance to the same list of SOP Classes as the Dicom- Server AE as SCP (see Section 3.4). Additionally the SOP classes in the following tables are supported.
SOP Class UID | SCP | SCU | |
Study Root Query/Retrieve Information Model – FIND | 1.2.840.10008.5.1.4.1.2.2.1 | - | Y |
Study Root Query/Retrieve Information Model – MOVE | 1.2.840.10008.5.1.4.1.2.2.2 | - | Y |
Table 1: Supported Query/Retrieve SOP classes
SOP Class UID | SCP | SCU | |
Basic Grayscale Print Management Meta SOP Class | 1.2.840.10008.5.1.1.9 | - | Y |
Presentation LUT SOP Class | 1.2.840.10008.5.1.1.23 | - | Y |
Basic Annotation Box SOP Class | 1.2.840.10008.5.1.1.15 | - | Y |
Table 2: Supported Print Management SOP classes
3.1.2 Association Establishment Policies
syngo.share view-ID AE supports TCP/IP. Upon a user requesting a C-FIND operation it will attempt to establish an association with a remote AE. The host, port and remote application entity title are defined within the user configuration dialog. The maximum PDU size accepted is 16384.
3.1.2.2 Number of Associations
syngo.share view-ID AE supports a single association for C-FIND operations. So only one C-FIND operation is in progress at any time. It must be finished or cancelled to allow a new C-FIND. Only one C-MOVE at a time will open an association to a remote AE at any time.
The syngo.share view-ID AE will only allow a single outstanding operation on each association. Therefore it will not perform asynchronous negotiation.
Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
Table 3: Implementation Details
3.1.2.4 Implementation Identifying Information
3.1.2.5 Association Initiation Policy by Real-World Activity
syngo.share view-ID AE initiates an association with a remote AE for C-FIND and C-MOVE requests. As a default the DICOM Implicit VR Little Endian Transfer Syntax (1.2.840.10008.1.2) as defined in DICOM 2013 PS 3.5, 10.1 is used. The accepted Transfer Syntaxes upon a sub association within a C-MOVE are defined in Table 4.
Explicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2.1
Explicit VR Big Endian Transfer Syntax 1.2.840.10008.1.2.2
Table 4: Supported view C-MOVE Transfer Syntaxes
The syngo.share import-FSR solely provides functionalities for handling DICOM media.
The webadmin AE solely provides functionality for retrieving DICOM media.
3.4.1 Supported SOP Classes and Transfer Syntaxes
Application Entity Specifications
DicomServer AE provides Standard Conformance to the DICOM Storage SOP classes listed in Table 6. Ta- ble 7 lists supported Private Storage SOP classes. The corresponding Storage Transfer Syntaxes can be found in Table 12.
SOP Class Name | SOP Class UID | SCP | SCU |
Stored Print Storage | 1.2.840.10008.5.1.1.27 | Y | Y |
Hardcopy Grayscale Image Storage | 1.2.840.10008.5.1.1.29 | Y | Y |
Hardcopy Color Image Storage | 1.2.840.10008.5.1.1.30 | Y | Y |
Computed Radiography Image Storage | 1.2.840.10008.5.1.4.1.1.1 | Y | Y |
Digital X-Ray Image Storage – For Presentation | 1.2.840.10008.5.1.4.1.1.1.1 | Y | Y |
Digital X-Ray Image Storage – For Processing | 1.2.840.10008.5.1.4.1.1.1.1.1 | Y | Y |
Digital Mammography X-Ray Image Storage – For Presentation | 1.2.840.10008.5.1.4.1.1.1.2 | Y | Y |
Digital Mammography X-Ray Image Storage – For Processing | 1.2.840.10008.5.1.4.1.1.1.2.1 | Y | Y |
Digital Intra-oral X-Ray Image Storage – For Pre- sentation | 1.2.840.10008.5.1.4.1.1.1.3 | Y | Y |
Digital Intra-oral X-Ray Image Storage – For Pro- cessing | 1.2.840.10008.5.1.4.1.1.1.3.1 | Y | Y |
CT Image Storage | 1.2.840.10008.5.1.4.1.1.2 | Y | Y |
Enhanced CT Image Storage | 1.2.840.10008.5.1.4.1.1.2.1 | Y | Y |
Legacy Converted Enhanced CT Image Storage | 1.2.840.10008.5.1.4.1.1.2.2 | Y | Y |
Ultrasound Multiframe Image Storage (Retired) | 1.2.840.10008.5.1.4.1.1.3 | Y | Y |
Ultrasound Multiframe Image Storage | 1.2.840.10008.5.1.4.1.1.3.1 | Y | Y |
MR Image Storage | 1.2.840.10008.5.1.4.1.1.4 | Y | Y |
Enhanced MR Image Storage | 1.2.840.10008.5.1.4.1.1.4.1 | Y | Y |
MR Spectroscopy Storage | 1.2.840.10008.5.1.4.1.1.4.2 | Y | Y |
Enhanced MR Color Image Storage SOP Class | 1.2.840.10008.5.1.4.1.1.4.3 | Y | Y |
Legacy Converted Enhanced MR Image Storage | 1.2.840.10008.5.1.4.1.1.4.4 | Y | Y |
Nuclear Medicine Image Storage (Retired) | 1.2.840.10008.5.1.4.1.1.5 | Y | Y |
Ultrasound Image Storage (Retired) | 1.2.840.10008.5.1.4.1.1.6 | Y | Y |
Ultrasound Image Storage | 1.2.840.10008.5.1.4.1.1.6.1 | Y | Y |
Enhanced US Volume Storage | 1.2.840.10008.5.1.4.1.1.6.2 | Y | Y |
Secondary Capture Image Storage | 1.2.840.10008.5.1.4.1.1.7 | Y | Y |
Multiframe Single Bit Secondary Capture Image Storage | 1.2.840.10008.5.1.4.1.1.7.1 | Y | Y |
Multiframe Grayscale Byte Secondary Capture Image Storage | 1.2.840.10008.5.1.4.1.1.7.2 | Y | Y |
Multiframe Grayscale Word Secondary Capture Image Storage | 1.2.840.10008.5.1.4.1.1.7.3 | Y | Y |
Multiframe True Color Secondary Capture Im- age Storage | 1.2.840.10008.5.1.4.1.1.7.4 | Y | Y |
Standalone Overlay Storage | 1.2.840.10008.5.1.4.1.1.8 | Y | Y |
Standalone Curve Storage | 1.2.840.10008.5.1.4.1.1.9 | Y | Y |
Waveform Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.9.1 | Y | Y |
12-lead ECG Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.1.1 | Y | Y |
General ECG Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.1.2 | Y | Y |
Ambulatory ECG Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.1.3 | Y | Y |
Hemodynamic Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.2.1 | Y | Y |
Cardiac Electrophysiology Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.3.1 | Y | Y |
Basic Voice Audio Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.4.1 | Y | Y |
General Audio Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.4.2 | Y | Y |
Arterial Pulse Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.5.1 | Y | Y |
Respiratory Waveform Storage | 1.2.840.10008.5.1.4.1.1.9.6.1 | Y | Y |
Standalone Modality LUT Storage | 1.2.840.10008.5.1.4.1.1.10 | Y | Y |
Standalone VOILUT Storage | 1.2.840.10008.5.1.4.1.1.11 | Y | Y |
Grayscale Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.1 | Y | Y |
Color Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.2 | Y | Y |
Application Entity Specifications
Pseudo-Color Softcopy Presentation State Stor- age SOP Class | 1.2.840.10008.5.1.4.1.1.11.3 | Y | Y |
Blending Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.4 | Y | Y |
XA/XRF Grayscale Softcopy Presentation State Storage | 1.2.840.10008.5.1.4.1.1.11.5 | Y | Y |
X-Ray Angiographic Image Storage | 1.2.840.10008.5.1.4.1.1.12.1 | Y | Y |
Enhanced XA Image Storage | 1.2.840.10008.5.1.4.1.1.12.1.1 | Y | Y |
X-Ray Fluoroscopy Image Storage | 1.2.840.10008.5.1.4.1.1.12.2 | Y | Y |
Enhanced XRF Image Storage | 1.2.840.10008.5.1.4.1.1.12.2.1 | Y | Y |
X-Ray Angiographic Bi-Plane Image Storage (Re- tired) | 1.2.840.10008.5.1.4.1.1.12.3 | Y | Y |
X-Ray 3D Angiographic Image Storage | 1.2.840.10008.5.1.4.1.1.13.1.1 | Y | Y |
X-Ray 3D Craniofacial Image Storage | 1.2.840.10008.5.1.4.1.1.13.1.2 | Y | Y |
Breast Tomosynthesis Image Storage | 1.2.840.10008.5.1.4.1.1.13.1.3 | Y | Y |
Breast Projection X-Ray Image Storage For Pre- sentation | 1.2.840.10008.5.1.4.1.1.13.1.4 | Y | Y |
Breast Projection X-Ray Image Storage For Pro- cessing | 1.2.840.10008.5.1.4.1.1.13.1.5 | Y | Y |
Intravascular Optical Coherence Tomography Image Storage – For Presentation | 1.2.840.10008.5.1.4.1.1.14.1 | Y | Y |
Intravascular Optical Coherence Tomography Image Storage – For Processing | 1.2.840.10008.5.1.4.1.1.14.2 | Y | Y |
Nuclear Medicine Image Storage | 1.2.840.10008.5.1.4.1.1.20 | Y | Y |
Raw Data Storage | 1.2.840.10008.5.1.4.1.1.66 | Y | Y |
Spatial Registration Storage | 1.2.840.10008.5.1.4.1.1.66.1 | Y | Y |
Spatial Fiducials Storage | 1.2.840.10008.5.1.4.1.1.66.2 | Y | Y |
Deformable Spatial Registration SOP Class | 1.2.840.10008.5.1.4.1.1.66.3 | Y | Y |
Segmentation SOP Class | 1.2.840.10008.5.1.4.1.1.66.4 | Y | Y |
Surface Segmentation Storage | 1.2.840.10008.5.1.4.1.1.66.5 | Y | Y |
Real World Value Mapping Storage | 1.2.840.10008.5.1.4.1.1.67 | Y | Y |
Surface Scan Mesh Storage | 1.2.840.10008.5.1.4.1.1.68.1 | Y | Y |
Surface Scan Point Cloud Storage | 1.2.840.10008.5.1.4.1.1.68.2 | Y | Y |
VL Image Storage (Retired) | 1.2.840.10008.5.1.4.1.1.77.1 | Y | Y |
VL Endoscopic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.1 | Y | Y |
Video Endoscopic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.1.1 | Y | Y |
VL Microscopic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.2 | Y | Y |
Video Microscopic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.2.1 | Y | Y |
VL Slide Coordinates Microscopic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.3 | Y | Y |
VL Photographic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.4 | Y | Y |
Video Photographic Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.4.1 | Y | Y |
Ophthalmic Photography 8 Bit Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.1 | Y | Y |
Ophthalmic Photography 16 Bit Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.2 | Y | Y |
Stereometric Relationship Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.3 | Y | Y |
Ophthalmic Tomography Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.4 | Y | Y |
Wide Field Ophthalmic Photography Stereo- graphic Projection Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.5 | Y | Y |
Application Entity Specifications
Wide Field Ophthalmic Photography 3D Coordi- nates Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.5.6 | Y | Y |
VL Whole Slide Microscopy Image Storage | 1.2.840.10008.5.1.4.1.1.77.1.6 | Y | Y |
VL Multi-frame Image Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.77.2 | Y | Y |
Lensometry Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.1 | Y | Y |
Autorefraction Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.2 | Y | Y |
Keratometry Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.3 | Y | Y |
Subjective Refraction Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.4 | Y | Y |
Visual Acuity Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.5 | Y | Y |
Spectacle Prescription Report Storage | 1.2.840.10008.5.1.4.1.1.78.6 | Y | Y |
Ophthalmic Axial Measurements Storage | 1.2.840.10008.5.1.4.1.1.78.7 | Y | Y |
Intraocular Lens Calculations Storage | 1.2.840.10008.5.1.4.1.1.78.8 | Y | Y |
Macular Grid Thickness and Volume Report | 1.2.840.10008.5.1.4.1.1.79.1 | Y | Y |
Ophthalmic Visual Field Static Perimetry Mea- surements Storage | 1.2.840.10008.5.1.4.1.1.80.1 | Y | Y |
Ophthalmic Thickness Map Storage | 1.2.840.10008.5.1.4.1.1.81.1 | Y | Y |
Corneal Topography Map Storage | 1.2.840.10008.5.1.4.1.1.82.1 | Y | Y |
Text SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.1 | Y | Y |
Audio SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.2 | Y | Y |
Detail SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.3 | Y | Y |
Comprehensive SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.4 | Y | Y |
Basic Text SR Storage | 1.2.840.10008.5.1.4.1.1.88.11 | Y | Y |
Enhanced SR Storage | 1.2.840.10008.5.1.4.1.1.88.22 | Y | Y |
Comprehensive SR Storage | 1.2.840.10008.5.1.4.1.1.88.33 | Y | Y |
Comprehensive 3D SR Storage | 1.2.840.10008.5.1.4.1.1.88.34 | Y | Y |
Procedure Log Storage | 1.2.840.10008.5.1.4.1.1.88.40 | Y | Y |
Mammography CAD SR Storage | 1.2.840.10008.5.1.4.1.1.88.50 | Y | Y |
Key Object Selection Document Storage | 1.2.840.10008.5.1.4.1.1.88.59 | Y | Y |
Chest CAD SR Storage | 1.2.840.10008.5.1.4.1.1.88.65 | Y | Y |
X-Ray Radiation Dose SR Storage | 1.2.840.10008.5.1.4.1.1.88.67 | Y | Y |
Radiopharmaceutical Radiation Dose SR Storage | 1.2.840.10008.5.1.4.1.1.88.68 | Y | Y |
Colon CAD SR | 1.2.840.10008.5.1.4.1.1.88.69 | Y | Y |
Implantation Plan SR Document Storage | 1.2.840.10008.5.1.4.1.1.88.70 | Y | Y |
Encapsulated PDF Storage | 1.2.840.10008.5.1.4.1.1.104.1 | Y | Y |
Encapsulated CDA Storage | 1.2.840.10008.5.1.4.1.1.104.2 | Y | Y |
PET Image Storage | 1.2.840.10008.5.1.4.1.1.128 | Y | Y |
Legacy Converted Enhanced PET Image Storage | 1.2.840.10008.5.1.4.1.1.128.1 | Y | Y |
PET Curve Storage | 1.2.840.10008.5.1.4.1.1.129 | Y | Y |
Enhanced PET Image Storage | 1.2.840.10008.5.1.4.1.1.130 | Y | Y |
Basic Structured Display Storage | 1.2.840.10008.5.1.4.1.1.131 | Y | Y |
RT Image Storage | 1.2.840.10008.5.1.4.1.1.481.1 | Y | Y |
RT Dose Storage | 1.2.840.10008.5.1.4.1.1.481.2 | Y | Y |
RT Structure Set Storage | 1.2.840.10008.5.1.4.1.1.481.3 | Y | Y |
RT Beams Treatment Record Storage | 1.2.840.10008.5.1.4.1.1.481.4 | Y | Y |
RT Plan Storage | 1.2.840.10008.5.1.4.1.1.481.5 | Y | Y |
RT Brachy Treatment Record Storage | 1.2.840.10008.5.1.4.1.1.481.6 | Y | Y |
RT Treatment Summary Record Storage | 1.2.840.10008.5.1.4.1.1.481.7 | Y | Y |
Application Entity Specifications
RT Ion Plan Storage | 1.2.840.10008.5.1.4.1.1.481.8 | Y | Y |
RT Ion Beams Treatment Record Storage | 1.2.840.10008.5.1.4.1.1.481.9 | Y | Y |
DICOS CT Image Storage | 1.2.840.10008.5.1.4.1.1.501.1 | Y | Y |
DICOS Digital X-Ray Image Storage – For Presen- tation | 1.2.840.10008.5.1.4.1.1.501.2.1 | Y | Y |
DICOS Digital X-Ray Image Storage – For Pro- cessing | 1.2.840.10008.5.1.4.1.1.501.2.2 | Y | Y |
DICOS Threat Detection Report Storage | 1.2.840.10008.5.1.4.1.1.501.3 | Y | Y |
Eddy Current Image Storage | 1.2.840.10008.5.1.4.1.1.601.1 | Y | Y |
Eddy Current Multi-frame Image Storage | 1.2.840.10008.5.1.4.1.1.601.2 | Y | Y |
RT Beams Delivery Instruction Storage – Trial (Retired) | 1.2.840.10008.5.1.4.34.1 | Y | Y |
RT Beams Delivery Instruction Storage | 1.2.840.10008.5.1.4.34.7 | Y | Y |
Generic Implant Template Storage | 1.2.840.10008.5.1.4.43.1 | Y | Y |
Implant Assembly Template Storage | 1.2.840.10008.5.1.4.44.1 | Y | Y |
Implant Template Group Storage | 1.2.840.10008.5.1.4.45.1 | Y | Y |
Table 6: Supported Storage SOP classes
SCP | SCU | |
GE Private 3D Model Storage 1.2.840.113619.4.26 | Y | Y |
GE Private PET Raw Data Storage 1.2.840.113619.4.30 | Y | Y |
Siemens CSA Non-Image Storage 1.3.12.2.1107.5.9.1 | Y | Y |
Philips Private 3D Presentation State Storage 1.3.46.670589.2.5.1.1 | Y | Y |
Philips Private Perfusion Storage 1.3.46.670589.5.0.13 | Y | Y |
Philips Private Perfusion Analysis Storage 1.3.46.670589.5.0.14 | Y | Y |
Philips Private MR Spectrum Storage 1.3.46.670589.11.0.0.12.1 | Y | Y |
Philips Private MR Series Data Storage 1.3.46.670589.11.0.0.12.2 | Y | Y |
Philips Private MR Examcard Data Storage 1.3.46.670589.11.0.0.12.4 | Y | Y |
Table 7: Supported Private Storage SOP classes |
SOP Class UID | SCP | SCU | |
Patient Root Query/Retrieve Information Model – FIND | 1.2.840.10008.5.1.4.1.2.1.1 | Y | Y |
Patient Root Query/Retrieve Information Model – MOVE | 1.2.840.10008.5.1.4.1.2.1.2 | Y | Y |
Patient Root Query/Retrieve Information Model – GET | 1.2.840.10008.5.1.4.1.2.1.3 | Y | - |
Study Root Query/Retrieve Information Model – FIND | 1.2.840.10008.5.1.4.1.2.2.1 | Y | Y |
Study Root Query/Retrieve Information Model – MOVE | 1.2.840.10008.5.1.4.1.2.2.2 | Y | Y |
Study Root Query/Retrieve Information Model – GET | 1.2.840.10008.5.1.4.1.2.2.3 | Y | - |
Modality Worklist Information Model – FIND | 1.2.840.10008.5.1.4.31 | Y | - |
Application Entity Specifications
Table 8: Supported Query/Retrieve SOP classes
For all non C-STORE SOP classes only “Implicit VR Little Endian: Default Transfer Syntax for DICOM” (1.2.840.10008.1.2) is supported.
The following C-STORE SCU/SCP transfer syntaxes are supported:
SOP Class UID | SCP | SCU | |
Verification | 1.2.840.10008.1.1 | Y | - |
Table 9: Supported Verification SOP classes | |||
SCP | SCU | ||
Storage Commitment Push Model 1.2.840.10008.1.20.1 | Y | - | |
Table 10: Supported Storage Commitment SOP classes | |||
SCP | SCU | ||
Modality Performed Procedure Step 1.2.840.10008.3.1.2.3.3 | Y | Y | |
Table 11: Supported Modality Performed Procedure Step SOP classes
UID | |
MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 | 1.2.840.10008.1.2.4.106 |
MPEG-4 AVC/H.264 High Profile / Level 4.2 for 3D Image Compression | 1.2.840.10008.1.2.4.105 |
MPEG-4 AVC/H.264 High Profile / Level 4.2 for 2D Image Compression | 1.2.840.10008.1.2.4.104 |
MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 | 1.2.840.10008.1.2.4.103 |
MPEG-4 AVC/H.264 High Profile / Level 4.1 | 1.2.840.10008.1.2.4.102 |
MPEG2 Main Profile @ High Level | 1.2.840.10008.1.2.4.101 |
MPEG2 Main Profile @ Main Level | 1.2.840.10008.1.2.4.100 |
JPEG 2000 Part 2 Multi-component Image Compression (Lossless Only) | 1.2.840.10008.1.2.4.92 |
JPEG 2000 Part 2 Multi-component Image Compression | 1.2.840.10008.1.2.4.93 |
JPEG 2000 Image Compression (Lossless Only) | 1.2.840.10008.1.2.4.90 |
JPEG 2000 Image Compression | 1.2.840.10008.1.2.4.91 |
JPEG-LS Lossless Image Compression | 1.2.840.10008.1.2.4.80 |
JPEG-LS Lossy (Near-Lossless) Image Compression | 1.2.840.10008.1.2.4.81 |
JPEG Lossless, Non-Hierarchical (Process 14) | 1.2.840.10008.1.2.4.57 |
JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selec- tion Value 1]): Default Transfer Syntax for Lossless JPEG Image Compres- | 1.2.840.10008.1.2.4.70 |
sion |
JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12 Bit Image Compression (Process 4 only)
age Compression | |
RLE Lossless | 1.2.840.10008.1.2.5 |
Deflated Explicit VR Little Endian | 1.2.840.10008.1.2.1.99 |
Explicit VR Little Endian | 1.2.840.10008.1.2.1 |
Explicit VR Big Endian | 1.2.840.10008.1.2.2 |
Implicit VR Little Endian: Default Transfer Syntax for DICOM | 1.2.840.10008.1.2 |
JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Im-
1.2.840.10008.1.2.4.51
1.2.840.10008.1.2.4.50
Application Entity Specifications
Table 12: Supported Storage Transfer Syntaxes
3.4.2 Association Establishment Policies
DicomServer AE supports plain TCP and TLS encrypted communication. For each kind of transport the server provides an arbitrary number of listen ports. All these ports are equivalent and provide the same
services.
The maximum PDU size accepted is 16384.
3.4.2.2 Number of Associations
DicomServer AE starts a thread for each incoming association request. The number of simultaneous asso- ciations is thus only limited by the hardware resources. DicomServer AE is configured for 30 simultaneous connections per default. This value can be changed without restarting the process.
DicomServer AE will only allow a single outstanding operation on an association. Therefore, it will not perform asynchronous negotiation.
3.4.2.4 Implementation Identifying Information
Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
Table 13: Implementation Details
DicomServer AE supports extended negotiation for C-FIND according to DICOM 2013 PS 3.4, C.5.1.1 for Patient Root Query/Retrieve and Study Root Query/Retrieve. The flags “Relational-queries” (Byte 1) and “Date-time matching” (Byte 2) are supported. “Fuzzy semantic matching of person names” (Byte 3) and “Timezone Query Adjustment” (Byte 4) are not supported and therefore always turned down by the SCP during association negotiation.
DicomServer AE supports extended negotiation for C-MOVE and C-GET according to DICOM 2013 PS 3.4,
C.5.2.1 and DICOM 2013 PS 3.4, C.5.3.1 for Patient Root Query/Retrieve and Study Root Query/Retrieve. “Relational-retrieval” (Byte 1) is supported.
3.4.3 Association Initiation Policy by Real-World Activity
3.4.3.1 Real-World Activity: C-MOVE Request Associated Real-World Activity
The DicomServer AE initiates an association when it receives a C-MOVE request.
Application Entity Specifications
Proposed Presentation Contexts
DicomServer AE picks all required SOP classes from Tables 6 and 7 and combines them with all Transfer Syntaxes from Table 12.
3.4.3.2 Real-World Activity: C-FIND Spanning Associated Real-World Activity
The DicomServer AE initiates associations to an arbitrary number of configured targets and forwards the incoming C-FIND request unaltered to each of them. The C-FIND request is also processed locally. Results that share common identifiers (i.e. share a common 4-tuple Patient ID, Study Instance UID, Series Instance UID and SOP Instance UID) are eliminated. Local results are always returned before any remote results are taken into account.
Proposed Presentation Contexts
The presentation context used for the incoming C-FIND request is used for the outgoing association.
3.4.3.3 Real-World Activity: C-MOVE Spanning Associated Real-World Activity
The DicomServer AE receives a C-MOVE request and the Called AET used in the incoming association matches the name of a configured DICOM target. In this case the C-MOVE request is forwarded unaltered to the corresponding configured targets.
Proposed Presentation Contexts
The presentation context used for the incoming C-MOVE request is used for the outgoing association.
3.4.4 Association Acceptance Policies
The DicomServer AE accepts an association when it receives a valid association request with at least one matching presentation context.
3.4.4.1 Real-World Activity: Storage SCU Associated Real-World Activity
The associated real world activity is a modality, workstation, PACS or other system attempting to store an image to the DicomServer AE. This results in storage of the received images in syngo.share.
Proposed Presentation Contexts
Tables 6, 7 and 12 constitute the Presentation Contexts that the DicomServer AE accepts from remote DICOM Storage SCUs during a C-STORE request.
Presentation Context Acceptance Criterion
The DicomServer AE accepts any of the Presentation Contexts that are constituted by the content of the Tables 6, 7 and 12.
3.4.4.2 KOS - Rejection Notes
On DICOM import KOS Rejection Notes are recognized by syngo.share (DicomServer) and lead to the behavior that each SOP Instance that is referenced by this KOS object is soft deleted iteratively from syngo.share.
Application Entity Specifications
Tag Concept Name Code Sequence in the KOS Rejection Note must contain exactly following information: CodingSchemeDesignator = “DCM”
CodeValue = 113001, 113037 or 113038
CodeMeaning = “Rejected for Quality Reasons”, “Rejected for Patient Safety Reasons” or “Incorrect Modality Worklist Entry”
The Current Requested Procedure Evidence Sequence contained in the KOS object may contain 1 to N studies and refers to all SOP Instances which should be soft deleted. It is not possible to delete Study Instance UIDs without having the whole hierarchy down to the Referenced SOP Sequence. The DICOM standard defines this hierarchy in DICOM 2013 PS 3.3 C.17.2.1.
The Referenced SOP Class UID has to comply with the SOP Class UID of the target instance. If referenced objects cannot be found or the SOP Class UIDs do not coincide, the KOS Rejection Note is imported, a warning is logged and no soft deletion of the respective SOP Instances occurs.
The EventServer AE provides a standard conformant support of the SOP classes mentioned in Table 14.
SOP Class UID SCP | SCU | |
Instance Availability Notification | 1.2.840.10008.5.1.4.33 - | Y |
Table 14: Supported Instance Availability Notification SOP classes
3.5.2 Association Establishment Policies
EventServer AE supports TCP/IP. If a DICOM XXX has to be send it will attempt to establish an association with a remote AE. The host, port and remote application entity title are defined within the configuration dialog.
3.5.2.2 Number of Associations
EventServer AE starts a thread for each configured receiving AE (note that it is possible that an AE is con- figured twice). The number of simultaneous associations is thus only limited by the hardware resources.
EventServer AE will only allow a single outstanding operation on each association. Therefore it will not perform asynchronous negotiation.
3.5.2.4 Implementation Identifying Information
Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
Table 15: Implementation Details
3.5.2.5 Association Initiation Policy by Real-World Activity
Application Entity Specifications
EventServer AE initiates an association with a remote AE for N-CREATE requests. As a default the DICOM Implicit VR Little Endian Transfer Syntax (1.2.840.10008.1.2) as defined in DICOM 2013 PS 3.5, 10.1 is used.
4 DICOM Media AE Specification
This chapter describes the DICOM Media functionalities of the syngo.share view-, syngo.share import- and webadmin-AEs.
4.1.1 Application Data Flow Diagram
See Section 2.1.1 (syngo.share view Data Flow Diagram), 2.1.2 (syngo.share import Data Flow Diagram) and 2.1.3 (webadmin Data Flow Diagram).
4.1.2 Functional Definitions of AEs
The syngo.share view- and syngo.share import-AEs implement standard DICOM conformant Service Classes for creating and reading DICOM file sets (according to DICOM 2013 PS 3.10). At least General Purpose CD-R Interchange Profiles are supported.
The webadmin AE implements a standard DICOM conformant Service class for retrieving DICOM images over Web Access for DICOM Persistent Objects (WADO).
4.1.3 Sequencing of Real World Activities
The DICOM Media functionalities of the syngo.share view- and syngo.share import-AEs can be used at any time through their user interfaces.
Also the webadmin-AE can be used at any time by the user or the application that performs the WADO request.
Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
Table 16: Implementation Details
4.2 Application Entity Specification
See Section 3.1 for supported SOP classes for import and export of media.
Application Profiles Supported | Real World Activity | Role | SC Option |
syngo.share view-FSR | Read DICOM file set | FSR | Interchange |
syngo.share view-FSC | Export DICOM file set | FSC | Interchange |
The complete file set is read for displaying purposes.
Reading DICOMDIR keys
All mandatory DICOMDIR keys are required in order to structure the images within the file sets appropri- ately.
Creating DICOMDIRs
view creates DICOMDIR with all mandatory keys as defined in DICOM 2013 PS 3.10.
Export Media
syngo.share view is able to organize DICOM images, series and studies into a single-patient file set which will then be written on portable media (e.g. CDs or DVDs). The view, here acting as a FSC, uses the following Transfer Syntaxes:
Transfer Syntax Name Transfer Syntax UID
Explicit VR Little Endian 1.2.840.10008.1.2.1
See Section 3.2 for supported SOP classes for import of media.
Application Profiles Supported Real World Activity Role SC Option
syngo.share import-FSR Read DICOM file set FSR Interchange
4.2.2.1 Real World Activities Import Media
The user can choose whether a complete file set or just parts of it are read for import.
Reading DICOMDIR keys
DICOM Media AE Specification
All mandatory DICOMDIR keys are required in order to structure the images within the file sets appropri- ately.
Application Profiles Supported Real World Activity Role SC Option
webadmin-AE WADO Request FSR Interchange
The user of the application that performs the WADO request can retrieve any DICOM image that exists in syngo.share, by identifying it with its DICOM study, series and image id’s. See DICOM 2013 PS 3.18 for more information.
4.3 Augmented and Private Application Profiles
DICOM Media AE Specification
Not used.
5 Communication Profiles
5.1 Supported Communication Stacks
DicomServer and EventServer provide plain TCP (see DICOM 2013 PS 3.8, 9) and TLS encrypted communi- cation (see DICOM 2013 PS 3.15, B.1). They uses OFFIS DICOM Tool Kit (DCMTK) for their communication which itself relies on the operating system it runs on.
6.1 Audit Trail Message Format Profile
To help assure healthcare privacy and security in automated systems, usage data need to be collected. These data will be reviewed by administrative staff to verify that healthcare data is being used in accor- dance with the healthcare provider’s data security requirements and to establish accountability for data use. This data collection and review process is called auditing and the data itself comprises the audit trail. Audit trails can be used for surveillance purposes to detect when interesting events might happened that warrant further investigation.
Auditing in syngo.share is implemented according to the IHE profile Audit Trail and Node Authentication (part Audit Trail) which is based on DICOM 2015a PS 3.15, A.5. Auditing is restricted to events regarding patients, documents, user authentications, hard-deletion configurations, and audit configuration:
search for patients or documents
creation, modification, or deletion of patients
import, modification, deletion, or export of documents login or logout of users
modification of hard-deletion configurations modification of the audit configuration
The processing of audit messages works asynchronously — events are recorded immediately, however, the resulting audit messages are queued and sent to an Audit Record Repository via TCP in periodic time intervals (the frequency of the intervals is configurable). If required, audit messages can be analyzed with an Audit Record Viewer. To use audit messages for effective system analyses, it is necessary that each audit message can be uniquely associated with a certain event. To this end each audit message provides various information. The most import ones are
the event ID,
the date and time of the event, the status of the event,
user IDs, application IDs, object IDs,
the audit trail ID (used to aggregate audit messages in order to reconstruct audit trails), and the audit source ID.
Within syngo.share the events recorded by audit messages are primarily identified via event IDs. However, since most event IDs represent a group of events rather than a single event it is often necessary to explore audit messages in detail to identify the reported events. In the following the event IDs used by syngo.share as well as some short instructions on how to identify events are given:
110102 (Begin Transferring DICOM Instances): This event ID is used to indicate the begin of an inter- nal or external transfer of DICOM Images. To differ between the two transfer types, one has to ana- lyze the participating destination application. If the destination application represents a syngo.share module, then an internal transfer has been performed. If it specifies a third-party system, an exter- nal transfer has been occurred.
110103 (DICOM Instances Accessed): This event ID is used in audit messages which are generated if DICOM Images are accessed, updated, moved, or undeleted. It is also used if parts of a DICOM Study are deleted (if a complete DICOM Study is deleted, the event ID 110105 (DICOM Study Deleted) is used instead). To differ between the mentioned operations one has to analyze the event action code ID as well as the objects stated in the audit message. If the event action code ID specifies an R, DICOM Images have been accessed. If the event action code ID defines an U, DICOM Images have been updated or moved (the life cycle of the DICOM Images indicates which of the two operations
has been executed). If the event action code ID specifies a C, DICOM Images have been undeleted. Finally, if the event action code ID states a D, DICOM images of a DICOM Study have been deleted. 110104 (DICOM Instances Transferred): The event ID 110104 is used to audit the end of an internal or external transfer of DICOM Images. In case of an internal transfer the source application represents a syngo.share module. If the source application defines a third-party system, the end of an external transfer has been audited.
110105 (DICOM Study Deleted): This event ID indicates the deletion of all DICOM Images of a DICOM Study. The life cycle information of the DICOM Study indicate whether the DICOM Study has been soft-deleted or hard-deleted.
110106 (Export): This event ID specifies the export of DICOM Images or generic files to a media. Detailed information about the exported DICOM Images or generic files can be obtained by analyzing the listed objects.
110107 (Import): Audit messages stating the event ID 110107 audit the import of DICOM Images or generic files from a media or the copy of DICOM Images or generic files. To obtain detailed information about the imported DICOM Images or generic files, the objects specified by the audit message should be analyzed.
110110 (Patient Record): Whenever the event ID 110110 appears in an audit messages, it indicates the creation, update, merge, deletion, or undeletion of a patient. To distinguish between the dif- ferent cases one has to analyze the event action code ID as well as the objects stated in the audit message. If the event action code ID specifies a C, a patient has been either created or undeleted. If the event action code ID states a U a patient has been updated or merged. Finally, if the event action code ID defines a D, a patient has been deleted. Two distinguish between the creation and undeletion of a patient as well as the update and merge of a patient one has to evaluate the life cycle information of the listed patients.
110112 (Query): This event ID indicates that either a DICOM C-FIND request or a SQL query has been performed. To differ between the two kinds of queries, one has to check if the object representing the query states a DICOM C-FIND request or a SQL query.
110113 (Security Alert): Audit messages stating the event ID 110113 describe the creation, update, or deletion of a system configuration (e.g., audit configuration, hard-deletion configuration, etc.). To decide which operation has been performed, the life cycle of the system configuration object has to be analyzed. Note that manipulations of the audit configuration are of peculiar interest because the audit configuration determines which events are audited.
110114 (User Authentication): This event ID is used to audit a login or logout. To differ between the two kinds of authentication, the event type codes have to be evaluated.
EI-001 (Begin Transferring Generic Instances): Via this event ID, the begin of an internal or external transfer of generic files is recorded. To analyze the kind of transfer type, a similar reasoning as for DICOM Images should be applied (see event ID 110102).
EI-002 (Generic Instances Transferred): This event ID indicates the end of an internal or external transfer of generic files. Similar as in case of event ID 110104 one has to analyze the source appli- cation (syngo.share module versus third-party system) to obtain the exact kind of transfer.
EI-003 (Generic Instances Accessed): The event ID EI-003 is used if generic files are accessed, updated, moved, or undeleted. It is also used if parts of a generic container are deleted (if a complete generic container is deleted, the event ID EI-004 (Generic Container Deleted) is used instead). To decide which operation has been performed, a similar reasoning as in case of DICOM Images should be applied (see event ID 110103).
EI-004 (Generic Container Deleted): This event ID indicates the deletion of all generic files of a
Security Profiles
generic container. The life cycle information of the generic container indicate whether the generic container has been soft-deleted or hard-deleted.
EI-005 (DICOM Study Share): This event ID is specified by audit messages which audit the creation or deletion of DICOM Study shares. Two differ between the two cases the event action code ID of the audit message has to be analyzed. If the event action code ID states a C, DICOM Studies have been shared. If it specifies a D existing DICOM Study shares have been deleted.
EI-006 (Generic Container Share): The event ID EI-006 indicates the creation or deletion of generic container shares. To decide which operation has been performed, a similar reasoning as in case of DICOM Study shares should be applied (see event ID EI-005).
To ensure that information provided by audit messages can be used to reconstruct and understand audited events, audit messages of various event IDs are equipped with different detailed information:
110102 (Begin Transferring DICOM Instances): Audit messages with this event ID are additionally equipped with the Series Instance UIDs (SOP Instance UIDs) of the affected DICOM Series (DICOM Images). Note that if neither Series Instance UIDs nor SOP Instance UIDs are specified, the whole DICOM Study has been involved in the occurred event.
110103 (DICOM Instances Accessed): Similarly to audit messages with event ID 110102, the Series Instance UIDs (SOP Instance UIDs) of the affected DICOM Series (DICOM Images) are specified (if neither Series Instance UIDs nor SOP Instance UIDs are specified, the whole DICOM Study has been affected). In addition, if DICOM Images are updated, detailed information about the changed values are provided.
110104 (DICOM Instances Transferred): See event ID 110102.
110106 (Export): Audit messages with this event ID specify additionally the Series Instance UIDs (SOP Instance UIDs, generic file UIDs) of the affected DICOM Series (DICOM Images, generic files). 110107 (Import): See event ID 110106.
110110 (Patient Record): If a patient has been updated, audit message with event ID 110110 are equipped with detailed information about the changed values.
110112 (Query): If an audit message with event ID 110112 records the execution of a C-FIND request, the transfer syntax of the C-FIND request is stated.
110113 (Security Alert): If a system configuration has been updated, audit messages with this event ID specify detailed information about the changed values. Additionally, an alert description is in- cluded independently whether a system configuration has been created, updated, or deleted.
EI-001 (Begin Transferring Generic Instances): An audit message with this event ID additionally states the generic file UIDs of the affected generic files. Note that if no generic file UIDs are listed, the whole generic container has been involved in the event.
EI-002 (Generic Instances Transferred): See event ID EI-001.
EI-003 (Generic Instances Accessed): Similarly to audit messages with event ID EI-001, the generic file UIDs of the affected generic files are specified (if no generic file UIDs are specified, the whole generic container has been affected). In addition, if generic files are updated, detailed information about the changed values are provided.
To simplify the analysis of audit messages generated by syngo.share, audit message are organized in so called audit trails. An audit trail represents a group of audit messages which have been created during the execution of a certain event (e.g. access of a DICOM Study, deletion of DICOM Images, transmis- sion of generic files, etc.). Since it might happen that several sub-events have to be performed in order to complete an event, within an audit trail audit messages are classified into sub and main audit mes- sages. Thereby, sub audit messages are used to audit necessary sub-events whereas main audit mes- sages are used to audit sufficient sub-events. To distinguish between different audit trails, each audit trail is equipped with a unique audit trail ID.
Security Profiles
Auditing must configured in webadmin. The most important configuration options are AuditSystemActions and AuditUserActions. The first one enables the auditing of actions trig- gered by systems or unknown users whereas the latter one ensures that actions triggered by registered users are audited. Since (automatic) events triggered by third-party systems are of minor interest but can lead to a tremendous amount of audit messages, it is recommended to enable the configuration key AuditUserActions but disable the configuration key AuditSystemActions.
For general information about auditing, please consult the syngo.share System Documentation.
7 Configuration
syngo.share view and syngo.share import provide user interfaces in order to facilitate configuration. Di- comServer and EventServer is configured according to the standard syngo.share server configuration mechanism which can be found in syngo.share System Documentation.
8
Support of Extended Character Sets
Table 17 contains the character sets which are supported with and without code extension techniques. If the given specific character set does not correspond to the characters in an IOD or the specific character set is invalid, the DICOM dataset will not be processed. In these cases a configuration can be used to correct the character set. Due to practical reasons the Specific Character Set is used instead of the Default Character Repertoire to process tags with VR CS.
8.2 Configuration capabilities
The specific character set of a C-STORE request can be corrected with a configuration. Furthermore the specific character set of the C-FIND request and response can be configured. For example the specific character set configuration values could be set to ’ISO_IR 192’, ’ISO_IR 100’, ’ISO 2022 IR 100\ISO 2022 IR 87’ etc.
During the processing of the C-FIND query attributes the specific character set of the request is considered. By default the response is encoded in ISO_IR 192 (UTF-8). If an alternate specific character set is config- ured for a C-FIND response, all characters which are not part of the given character set are exchanged by the replacement character ’?’. If the query contains the attribute PatientName, only the alphabetic com- ponent group is used for search. In the response, attributes with the value representation PN contain all component groups (alphabetic, ideographic and phonetic).
MIME Name Without Code Extensions With Code Extensions
US-ASCII | ISO_IR | 6 | ISO | 2022 | IR | 6 |
ISO-8859-1 | ISO_IR | 100 | ISO | 2022 | IR | 100 |
ISO-8859-2 | ISO_IR | 101 | ISO | 2022 | IR | 101 |
ISO-8859-3 | ISO_IR | 109 | ISO | 2022 | IR | 109 |
ISO-8859-4 | ISO_IR | 110 | ISO | 2022 | IR | 110 |
ISO-8859-5 | ISO_IR | 144 | ISO | 2022 | IR | 144 |
ISO-8859-6 | ISO_IR | 127 | ISO | 2022 | IR | 127 |
ISO-8859-7 | ISO_IR | 126 | ISO | 2022 | IR | 126 |
ISO-8859-8 | ISO_IR | 138 | ISO | 2022 | IR | 138 |
ISO-8859-9 | ISO_IR | 148 | ISO | 2022 | IR | 148 |
JIS_X0201 | ISO_IR | 13 | ISO | 2022 | IR | 13 |
TIS-620 | ISO_IR | 166 | ISO | 2022 | IR | 166 |
JIS_X0208-1990 | - | ISO | 2022 | IR | 87 | |
JIS_X0212-1990 | - | ISO | 2022 | IR | 159 | |
KS_X_1001-1997 | - | ISO | 2022 | IR | 149 | |
GB2312 | - | ISO | 2022 | IR | 58 | |
UTF-8 | ISO_IR | 000 | - | |||
XX00000 | GB18030 | - | ||||
GBK | GBK | - |
Support of Extended Character Sets
Table 17: Supported Character Sets
A
Key list for
Query/Retrieve-Service classes
In the following, the DICOM keys which are used for matching on Patient, Study, Series and Image level in C-FIND requests are listed. All keys are supported for matching and response. Person Name fields are always matched case-insensitive. The attribute Specific Character Set (0008,0005) shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier.
A.1 Keys for C-FIND requests on Patient Level
Key | Tag | Remark |
PatientID | (0010,0020) | |
PatientName | (0010,0010) | |
PatientBirthDate | (0010,0030) | Combined Date/TimeMatching supported |
PatientBirthTime | (0010,0032) | Combined Date/TimeMatching supported |
PatientSex | (0010,0040) |
A.2 Keys for C-FIND requests on Study Level
In case of Study Root Query/Retrieve, where no Patient level exists, all mentioned Patient level keys are supported on level Study.
Key | Tag | Remark |
StudyInstanceUID | (0020,000D) | |
StudyDate | (0008,0020) | Combined Date/TimeMatching supported |
StudyTime | (0008,0030) | Combined Date/TimeMatching supported |
StudyDescription | (0008,1030) | |
AccessionNumber | (0008,0050) | |
StudyID | (0020,0010) | |
NumberOfStudyRelatedSeries | (0020,1206) | |
NumberOfStudyRelatedInstances | (0020,1208) | |
ReferringPhysicianName | (0008,0090) | |
ModalitiesInStudy | (0008,0061) |
A.3 Keys for C-FIND requests on Series Level
Key Tag Remark
SeriesInstanceUID (0020,000E)
Modality (0008,0060)
SeriesNumber (0020,0011)
SeriesDescription (0008,103E)
NumberOfSeriesRelatedInstances | (0020,1209) | |
InstitutionName | (0008,0080) | |
InstitutionalDepartmentName | (0008,1040) | |
StationName | (0008,1010) | |
PerformingPhysicianName | (0008,1050) | |
Manufacturer | (0008,0070) | |
ManufacturerModelName | (0008,1090) | |
BodyPartExamined | (0018,0015) | |
OperatorsName | (0008,1070) | |
PerformedProcedureStepStartDate | (0040,0244) | Combined Date/Time Matching supported |
PerformedProcedureStepStartTime | (0040,0245) | Combined Date/Time Matching supported |
PerformedProcedureStepEndDate | (0040,0250) | Combined Date/Time Matching supported |
PerformedProcedureStepEndTime | (0040,0251) | Combined Date/Time Matching supported |
SeriesDate | (0008,0021) | Combined Date/Time Matching supported |
SeriesTime | (0008,0031) | Combined Date/Time Matching supported |
RequestAttributesSequence/ | (0040,0275)/ | |
RequestedProcedureID | (0040,1001) | |
RequestAttributesSequence/ | (0040,0275)/ | |
ScheduledProcedureStepID | (0040,0009) |
Key list for Query/Retrieve-Service classes
A.4 Keys for C-FIND requests on Image Level
Key | Tag | Remark |
SOPInstanceUID | (0008,0018) | |
InstanceNumber | (0020,0013) | |
SOPClassUID | (0008,0016) | |
Rows | (0028,0010) | |
Columns | (0028,0011) | |
BitsAllocated | (0028,0100) | |
BitsStored | (0028,0101) | |
SamplesPerPixel | (0028,0002) | |
NumberOfFrames | (0028,0008) | |
ContentTemplateSequence/ TemplateIdentifier | (0040,A504)/ (0040,DB00) | * |
ContentTemplateSequence/ MappingResource | (0040,A504)/ (0008,0105) | * |
ContentDate | (0008,0023) | * |
ContentTime | (0008,0033) | * |
ObservationDateTime | (0040,A032) | * |
ReferencedRequestSequence/ StudyInstanceUID | (0040,A370)/ (0020,000D) | * |
ReferencedRequestSequence/ AccessionNumber | (0040,A370)/ (0008,0050) | * |
ReferencedRequestSequence/ RequestedProcedureID | (0040,A370)/ (0040,1001) | * |
ReferencedRequestSequence/ | (0040,A370)/ | * |
RequestedProcedureCodeSequence/ | (0032,1064)/ | |
CodeValue | (0008,0100) | |
ReferencedRequestSequence/ | (0040,A370)/ | * |
RequestedProcedureCodeSequence/ | (0032,1064)/ | |
CodingSchemeDesignator | (0008,0102) | |
ReferencedRequestSequence/ | (0040,A370)/ | * |
RequestedProcedureCodeSequence/ | (0032,1064)/ | |
CodingSchemeVersion | (0008,0103) | |
ReferencedRequestSequence/ | (0040,A370)/ | * |
RequestedProcedureCodeSequence/ | (0032,1064)/ | |
CodeMeaning | (0008,0104) | |
ConceptNameCodeSequence/ CodeValue | (0040,A043)/ (0008,0100) | * |
ConceptNameCodeSequence/ CodingSchemeDesignator | (0040,A043)/ (0008,0102) | * |
ConceptNameCodeSequence/ CodingSchemeVersion | (0040,A043)/ (0008,0103) | * |
ConceptNameCodeSequence/ CodeMeaning | (0040,A043)/ (0008,0104) | * |
CompletionFlag | (0040,A491) | * |
VerificationFlag | (0040,A493) | * |
VerifyingObserverSequence/ VerifyingOrganization | (0040,A073)/ (0040,A027) | * |
VerifyingObserverSequence/ VerificationDateTime | (0040,A073)/ (0040,A030) | * |
VerifyingObserverSequence/ VerifyingObserverName | (0040,A073)/ (0040,A075) | * |
VerifyingObserverSequence/ VerifyingObserverIdentificationCodeSequence/ CodeValue | (0040,A073)/ (0040,A088)/ (0008,0100) | * |
VerifyingObserverSequence/ VerifyingObserverIdentificationCodeSequence/ CodingSchemeDesignator | (0040,A073)/ (0040,A088)/ (0008,0102) | * |
VerifyingObserverSequence/ VerifyingObserverIdentificationCodeSequence/ CodingSchemeVersion | (0040,A073)/ (0040,A088)/ (0008,0103) | * |
VerifyingObserverSequence/ VerifyingObserverIdentificationCodeSequence/ CodeMeaning | (0040,A073)/ (0040,A088)/ (0008,0104) | * |
ContentLabel | (0070,0080) | * |
ContentDescription | (0070,0081) | * |
Key list for Query/Retrieve-Service classes
PresentationCreationDate | (0070,0082) | * |
PresentationCreationTime | (0070,0083) | * |
ContentCreatorName | (0070,0084) | * |
ReferencedSeriesSequence/ SeriesInstanceUID | (0008,1115)/ (0020,000E) | * |
ReferencedSeriesSequence/ | (0008,1115)/ | * |
ReferencedImageSequence/ | (0008,1140)/ | |
ReferencedSOPClassUID | (0008,1150) | |
ReferencedSeriesSequence/ | (0008,1115)/ | * |
ReferencedImageSequence/ | (0008,1140)/ | |
ReferencedSOPInstanceUID | (0008,1155) |
* These keys are only supported when used in conjunction with one of the following SOP classes
SOP Class Name | SOP Class UID |
Grayscale Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.1 |
Color Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.2 |
Pseudo-Color Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.3 |
Blending Softcopy Presentation State Storage SOP Class | 1.2.840.10008.5.1.4.1.1.11.4 |
Basic Text SR Storage | 1.2.840.10008.5.1.4.1.1.88.11 |
Enhanced SR Storage | 1.2.840.10008.5.1.4.1.1.88.22 |
Comprehensive SR Storage | 1.2.840.10008.5.1.4.1.1.88.33 |
Mammography CAD SR Storage | 1.2.840.10008.5.1.4.1.1.88.50 |
Chest CAD SR Storage | 1.2.840.10008.5.1.4.1.1.88.65 |
X-Ray Radiation Dose SR Storage | 1.2.840.10008.5.1.4.1.1.88.67 |
Text SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.1 |
Audio SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.2 |
Detail SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.3 |
Comprehensive SR Storage – Trial (Retired) | 1.2.840.10008.5.1.4.1.1.88.4 |
Key Object Selection Document Storage | 1.2.840.10008.5.1.4.1.1.88.59 |
Key list for Query/Retrieve-Service classes
A.5 Keys for C-FIND requests issued by view on Study Level
Key | Tag | Remark |
PatientID | (0010,0020) | |
PatientName | (0010,0010) | |
PatientBirthDate | (0010,0030) | |
PatientSex | (0010,0040) | |
StudyDate | (0008,0020) | |
StudyDescription | (0008,1030) | |
AccessionNumber | (0008,0050) | |
ModalitiesInStudy StudyInstanceUID NumberOfStudyRelatedSeries | (0008,0061) (0020,000d) (0020,1206) | |
NumberOfStudyRelatedInstances | (0020,1208) |
B
Key list for Modality Worklist
C-FIND requests
Modality Worklist queries support all C-FIND keys from Level Patient. The attribute Specific Character Set (0008,0005) shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier.
Key | Tag | Remark |
AdmissionID | (0038,0010) | |
CurrentPatientLocation | (0038,0300) | |
ConfidentialityConstraintOnPatientDataDescription | (0040,3001) | |
PregnancyStatus | (0010,21C0) | |
ReferringPhysicianName | (0008,0090) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | |
ScheduledStationAETitle | (0040,0001) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | Combined |
ScheduledProcedureStepStartDate | (0040,0002) | Date/Time Matching supported |
ScheduledProcedureStepSequence/ | (0040,0100)/ | Combined |
ScheduledProcedureStepStartTime | (0040,0003) | Date/Time Matching supported |
ScheduledProcedureStepSequence/ | (0040,0100)/ | |
Modality | (0008,0060) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | |
ScheduledPerformingPhysicianName | (0040,0006) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
ScheduledProcedureStepDescription | (0040,0007) | response only |
ScheduledProcedureStepSequence/ | (0040,0100)/ | |
ScheduledProcedureStepID | (0040,0009) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
ScheduledProtocolCodeSequence/ | (0040,0008)/ | response only |
CodeValue | (0008,0100) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
ScheduledProtocolCodeSequence/ | (0040,0008)/ | response only |
CodingSchemeDesignator | (0008,0102) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
ScheduledProtocolCodeSequence/ | (0040,0008)/ | response only |
CodeMeaning | (0008,0104) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
RequestedProcedureCodeSequence/ | (0032,1064)/ | response only |
CodeValue | (0008,0100) |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
RequestedProcedureCodeSequence/ | (0032,1064)/ | response only |
CodingSchemeDesignator | (0008,0102) | |
ScheduledProcedureStepSequence/ | (0040,0100)/ | no matching, |
RequestedProcedureCodeSequence/ | (0032,1064)/ | response only |
CodeMeaning | (0008,0104) | |
RequestedProcedureID | (0040,1001) | |
RequestedProcedureDescription | (0032,1060) | no matching, response only |
StudyInstanceUID | (0020,000D) | |
AccessionNumber | (0008,0050) | |
RequestingPhysician | (0032,1032) | |
OrderCallbackPhoneNumber | (0040,2010) | |
PlacerOrderNumberImagingServiceRequest | (0040,2016) | |
FillerOrderNumberImagingServiceRequest | (0040,2017) | |
OrderEntererLocation | (0040,2009) | |
PatientState | (0038,0500) | |
MedicalAlerts | (0010,2000) |
Key list for Modality Worklist C-FIND requests
Distributed by
Siemens Healthcare GmbH Xxxxxxxx. 000
00000 Xxxxxxxx Xxxxxxx
Phone: x00 0000 00-0
xxxxxxx.xxx/xxxxxxxxxx
Legal Manufacturer
ITH icoserve technology for healthcare XxxX
Xxxxxxx 00
0000 Xxxxxxxxx
Xxxxxxx Phone: x00 000 00000
xxx.xxxxxxx.xxx/xxxxx.xxxxx Made in Austria
Distributed by:
s
HL7 Conformance Statement
syngo.share / Release VA23B / 2016-03-14
About This Document
Target Group
This document is intended for personnel working in health care information technology, including project managers, solution consultants, and developers.
Purpose
This document describes syngo.share’s compliance with the HL7 messaging standard, IHE IT Infrastructure Technical Framework revision 11.0, and IHE Radiology Technical Framework revision 13.0.
This document was typeset with X LATEX
Table of Contents
1 Introduction 4
1.1 HL7 Message Syntax 4
1.1.1 HL7 Message Delimiters 4
1.1.2 Character Sets 4
1.2 HL7 Communication 6
1.3 Preliminaries 7
2 HL7 Inbound Interface 8
2.1 Patient and Visit Administration 8
2.1.1 Operating Mode 8
2.1.2 HL7 ADT Message Structure 9
2.2 Order Administration 10
2.2.1 Operating Mode 10
2.2.2 HL7 OMI Message Structure 11
2.2.3 HL7 ORM Message Structure 12
2.3 Archiving of Generic Files 13
2.3.1 Operating Mode 13
2.3.2 HL7 MDM Message Structure 14
2.3.3 HL7 ORU Message Structure 15
2.4 Sharing of DICOM Studies and Generic Containers 16
2.4.1 Operating Mode 16
2.4.2 HL7 ORU Message Structure 16
2.5 Deletion of DICOM Studies and Generic Containers 16
2.5.1 Operating Mode 16
2.5.2 HL7 ORU Message Structure 17
2.6 HL7 Segments 17
2.6.1 HL7 MSH Segment 17
2.6.2 HL7 PID Segment 18
2.6.3 HL7 MRG Segment 19
2.6.4 XX0 XX0 Segment 19
2.6.5 HL7 PV1 Segment 20
2.6.6 HL7 ROL Segment 20
2.6.7 HL7 GT1 Segment 21
2.6.8 HL7 ORC Segment 21
2.6.9 XX0 XX0 Segment 22
2.6.10 HL7 OBR Segment 22
2.6.11 HL7 IPC Segment 24
2.6.12 HL7 TXA Segment 25
2.6.13 HL7 OBX Segment 27
2.6.14 HL7 PRT Segment 29
2.6.15 HL7 ZDS Segment 29
3 HL7 Outbound Interface 30
3.1 Routing of Generic Files 30
3.1.1 Operating Mode 30
3.1.2 HL7 MDM Message Structure 31
3.2 Referencing of DICOM Studies and Generic Containers 31
3.2.1 Operating Mode 31
3.2.2 HL7 ORU Message Structure 32
3.3 Acknowledging of Processed HL7 Messages 32
3.3.1 Operating Mode 32
3.3.2 HL7 Application Acknowledgment Message Structure 32
3.4 HL7 Segments 33
3.4.1 HL7 MSH Segment 33
3.4.2 HL7 PID Segment 33
3.4.3 HL7 PV1 Segment 34
3.4.4 HL7 ORC Segment 34
3.4.5 HL7 OBR Segment 35
3.4.6 HL7 TXA Segment 35
3.4.7 HL7 OBX Segment 36
3.4.8 HL7 MSA Segment 38
A Example Workflows 39
A.1 Ordering of DICOM Studies 39
A.2 Archiving of Generic Files 50
A.3 Referencing of DICOM Studies and Generic Containers 57
List of Tables
1 Character Sets and Alternate Character Set Handling Schemes 5
List of Figures
1 Ordering Workflow 39
2 Generic Archiving Workflow 50
3 Reference Pointer Workflow 57
1 Introduction
The HL7 interface of syngo.share is designed according to the HL7 Messaging Standard, version 2.8.1 as well as the IHE IT Infrastructure Technical Framework, revision 11.0 and IHE Radiology Technical Frame- work, revision 13.0. The primary goal of the HL7 interface of syngo.share is the synchronization with third-party systems within healthcare settings. To achieve this goal syngo.share is able to receive and process various kinds of HL7 messages. To inform third-party system about changes, syngo.share also provides the possibility to generate and send HL7 messages.
To establish a successful exchange of data with third-party systems, this document addresses all require- ments and specialties of the HL7 interface of syngo.share. In the remainder of this section details of the HL7 communication as well as the HL7 message syntax are described. Afterwards, the HL7 inbound and outbound interface of syngo.share are discussed by specifying the layout of the supported HL7 messages, how they are processed or generated, as well as the workflows in which they occur. Since the HL7 inbound and outbound interface are strictly separated within syngo.share, they are covered in different sections.
To be able to parse and in the following process HL7 messages, syngo.share requires that HL7 messages have been generated according to the guidelines of the HL7 Messaging Standard. On this account spe- cial attention has to be turned on the specification of the HL7 message delimiters (HL7 fields MSH-1 and MSH-2), the character sets (HL7 field MSH-18), and the alternate character set handling scheme (HL7 field MSH-20) as well as the use of the HL7 segment terminator.
The HL7 message delimiters of a HL7 message are detected automatically by syngo.share and can be defined individually. To ensure that the detection succeeds it has to be guaranteed that the HL7 field separator is a US-ASCII character and the HL7 component separator, the HL7 subcomponent separator, the repetition separator, the escape character, and the truncation character are characters of the default character set of the HL7 message. However it is not allowed to use the US-ASCII characters carriage return (hexadecimal 0d), escape (hexadecimal 1b), and " (hexadecimal 22) as HL7 message delimiters because they are used as HL7 segment terminator, character set escape character (cf. alternate character set handling scheme ISO 2022-1994), and null character. Although the HL7 message delimiters can be defined individually, it is recommended by syngo.share to use the default HL7 message delimiters defined by the HL7 Messaging Standard. To guarantee that the end of a HL7 segment can be detected, syngo.share requires that each HL7 segment, also the last one, is terminated by the HL7 segment terminator. As HL7 segment terminator syngo.share expects a carriage return (hexadecimal 0d).
The HL7 interface of syngo.share is fully internationalized. To this end, the character sets used within a HL7 message are detected automatically by extracting the corresponding information from the HL7 field MSH-18. The first character set defines the default character set of a HL7 message. All other character sets define so called alternate character sets which can be used to specify characters which are not part of the default character set. If no character set is defined syngo.share assumes, in accordance with the
Alternate Character Set Handling Schemes
2.3 | ISO 2022-1994 | ||||
Character Set | MIME Name | GL | GR | GL | GR |
ASCII | US-ASCII | C2842 | 2842 | ||
8859/1 | ISO-8859-1 | C2842 | C2D41 | 2842 | 2d41 |
8859/2 | ISO-8859-2 | C2842 | C2D42 | 2842 | 2d42 |
8859/3 | ISO-8859-3 | C2842 | C2D43 | 2842 | 2d43 |
8859/4 | ISO-8859-4 | C2842 | C2D44 | 2842 | 2d44 |
8859/5 | ISO-8859-5 | C2842 | C2D4C | 2842 | 2d4c |
8859/6 | ISO-8859-6 | C2842 | C2D47 | 2842 | 2d47 |
8859/7 | ISO-8859-6 | C2842 | C2D46 | 2842 | 2d46 |
8859/8 | ISO-8859-8 | C2842 | C2D48 | 2842 | 2d48 |
8859/9 | ISO-8859-9 | C2842 | C2D4D | 2842 | 2d4d |
8859/15 | ISO-8859-15 | ||||
ISO IR6 | US-ASCII | C2842 | 2842 | ||
ISO IR14 | JIS_X0201 | C284A | C2949 | 284a | 2949 |
ISO IR87 | JIS_X0208-1990 | M2442 | 2442 | ||
ISO IR159 | JIS_X0212-1990 | M242844 | 000000 | ||
XX X 0000 | KS_X_1001-1997 | M242943 | 242943 | ||
CNS 11643-1992 | EUC-TW | ||||
GB 18030-2000 | GB18030 | ||||
BIG-5 | Big5 | ||||
UNICODE UTF-8 | UTF-8 | ||||
UNICODE UTF-16 | UTF-16 | ||||
UNICODE UTF-32 | UTF-32 | ||||
Table 1: Character Sets and Alternate Character Set Handling Schemes
Introduction
HL7 Messaging Standard, that all characters used within a given HL7 message are part of US-ASCII. If alternate character sets are specified, the handling scheme of the alternate character sets (determines how character set switches are indicated) has to be defined by the HL7 field MSH-20. If the character sets or the alternate character set handling scheme of a HL7 message are incomplete or incorrect, syngo.share will not be able to parse the HL7 message. Table 1 lists the character sets, the MIME names of the character sets, the alternate character set handling schemes, and the escape sequences of the character sets with respect to the alternate character set handling schemes, that are supported by xxxxx.share. The character sets XXX XX00, XXX XX000, and KS X 1001 only can be used as alternate character sets because they do not build up on US-ASCII. In contrast the character sets 8859/15, CNS 11643-1992, GB 18030-2000, XXX-0, XXXXXXX XXX-0, XXXXXXX XXX-00, and UNICODE UTF-32 cannot be mixed with other character sets because for these character sets no escape sequences are provided. Note that in case of the character sets GB 18030-2000, UNICODE XXX-0, XXXXXXX XXX-00, and UNICODE UTF-32 that would be useless anyway because they can encode all characters of the Unicode Standard. The endianness of the character sets UNICODE UTF-16 and UNICODE UTF-32 is detected automatically by syngo.share. So both the little- endian and big-endian variants of UTF-16 and UTF-32 are supported. To allow switches between multiple character sets, syngo.share applies the rules defined by the HL7 Messaging Standard as well as ISO/IEC 2022 and ECMA-35. Following these standards, character sets are divided into a GL (lower bytes between 20 and 7f) and GR (higher bytes between a0 and ff) level. To ensure that the characters of the GL or GR level of a character set can be used, the desired character set switch has to be triggered by specifying the corresponding escape sequence. Note that the escape sequences of the alternate character set handling scheme ISO 2022-1994, mentioned in Table 1, are stated in hexadecimal. Since HL7 message delimiters have to be specified in the default character set, the scope of a character set switch is limited to the HL7 subcomponent in which it occurs. So, at the end of each HL7 subcomponent the character sets defined
by the GL and GR level must be switched back to the default character set, if necessary.
To communicate with third-party systems syngo.share uses TCP/IP connections based on the Minimal Lower Layer Protocol specified by the HL7 Messaging Standard. Within HL7 communications syngo.share can act either as receiver or sender of HL7 messages. If syngo.share receives HL7 messages, it is assumed that the connecting third-party system administrates the HL7 connection. This means, the HL7 connec- tion is not closed by syngo.share as long as no irreparable error occurs. Vice versa, if syngo.share sends HL7 messages to a third-party system it assumes that it controls the HL7 connection. To be robust against network problems, the HL7 outbound interface of syngo.share opens a HL7 connection if and only if HL7 messages have to be transmitted to a third-party system and closes an established HL7 connection as soon as all HL7 messages have been sent. To avoid that HL7 connections are established and terminated frequently, syngo.share waits a configured amount of time before it reestablishes a HL7 connection to exchange further HL7 messages.
To receive and send HL7 messages syngo.share follows either the original or enhanced processing rules specified by the HL7 Messaging Standard. A received HL7 message is processed according to the original processing rules if the accept acknowledgment type (see HL7 field MSH-15) and application acknowledg- ment type (see HL7 field MSH-16) are null or not present. If the accept acknowledgment type or applica- tion acknowledgment type are specified the enhanced processing rules are used to exchange the sent HL7 message. If syngo.share acts as a HL7 message sender it has to be configured whether the original or en- hanced processing rules should be used to transmit HL7 messages. In the latter case syngo.share requires the transmission of HL7 accept acknowledgment messages but denies the exchange of HL7 application acknowledgment messages. To complement the two processing modes syngo.share also supports the Sequence Number Protocol defined by the HL7 Messaging Standard.
Introduction
Each time syngo.share receives a HL7 message it is checked for syntactic and semantic correctness. If the HL7 message is syntactically incorrect it cannot be parsed by syngo.share and hence neither be stored nor processed. Since the sending third-party system cannot be informed about syntactic errors even if the transmission of an HL7 accept acknowledgment message has been requested, the HL7 connection is closed by syngo.share. To validate the HL7 message semantically, it is checked by syngo.share if the type of the HL7 message can be processed and the receiving facility specified by the HL7 field MSH-6 is related to one of the configured tenants. If the type of the received HL7 message is not supported by syngo.share the received HL7 message is rejected. To this end a HL7 accept acknowledgment message with the acknowledgment code AR or CR (the former code is specified if the original processing rules are applied, the latter one if the enhanced processing rules are used) is sent to the sending third-party system if the receiving of the HL7 message has to be acknowledged. If the type of the received HL7 message can be processed by syngo.share but the receiving facility does not address any of the configured tenants, the HL7 message is stored on the file system within a configured error directory. To inform the sending third-party system about the occurred error, a HL7 accept acknowledgment message with the acknowledgment code AE or CE (the former code is specified if the original processing rules are applied, the latter one if the enhanced processing rules are used) is sent back, if demanded. In case that the syntactic and semantic checks succeed, the received HL7 message is stored by syngo.share and scheduled for processing. If the receiving of the HL7 message has to be acknowledged, this time a HL7 accept acknowledgment message specifying the acknowledgment code AA or CA (the former code is specified if the original processing rules are applied, the latter one if the enhanced processing rules are used) is sent. If a HL7 message is transferred according to the enhanced processing rules it might be necessary to exchange further information with the sending third-party system as soon as the HL7 message has been processed. To this end syngo.share is able to send so called HL7 application acknowledgment messages (see Section 3.3 for further information).
If syngo.share sends a HL7 message to a third-party system it always expects that the received HL7 mes- sage is acknowledged. In case of a positive acknowledgment syngo.share demands that the HL7 accept acknowledgment message specifies the acknowledgment code AA if the original processing rules are used to transmit the HL7 message and the acknowledgment code CA if the enhanced processing rules are used to exchange the HL7 message. Note that it can be individually configured in syngo.share which processing rules should be used to transfer HL7 messages.
The chronological order in which received HL7 messages are stored by syngo.share defines the chronolog- ical order in which the HL7 messages will be processed. So to guarantee that HL7 messages are processed correctly, they should always be sent in the correct chronological order. Vice versa, if syngo.share sends HL7 messages to a third-party system, it always guarantees that HL7 messages which depend on each other are transmitted in chronological order.
In the remainder of the document it is assumed that for incoming HL7 messages R (C, O) is used to in- dicate that a HL7 segment, HL7 field, HL7 component, or HL7 subcomponent is required (conditionally required, optional). In case of outgoing HL7 messages R defines that a HL7 segment, HL7 field, HL7 com- ponent, or HL7 subcomponent is always specified by syngo.share whereas C and O denote that a HL7 segment, HL7 field, HL7 component, or HL7 subcomponent is just specified under certain circumstances or if syngo.share possesses the corresponding information. HL7 segments, XX0 xxxxxx, XX0 components, and HL7 subcomponents which are not mentioned, are ignored and hence not evaluated by syngo.share. For some of the listed HL7 segments, XX0 xxxxxx, XX0 components, or HL7 subcomponents length infor- mation are declared. This indicates, that the corresponding HL7 segment, HL7 field, HL7 component, or HL7 subcomponent is stored in the database which limits the number of characters that can be used to define it. If the length of a HL7 segment, HL7 field, HL7 component, or HL7 subcomponent exceeds the defined limit, the provided information cannot be stored and hence the HL7 message cannot be pro- cessed successfully. If the length of a HL7 segment, HL7 field, HL7 component, or HL7 subcomponent is not stated, the information is not stored by syngo.share although it might be needed to process the HL7 message correctly.
As required by the HL7 Messaging Standard it is assumed that all date and time information is formatted according to the following standardized format:
YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].
Timestamps which do not possess timezone information are assumed to be in local time. To avoid prob- lems with timestamp conversions, all timestamps specified in HL7 messages sent by syngo.share are given in local time and hence do not specify any timezone offsets.
In general the HL7 Messaging Standard strictly differs between the insertion and update of information. Since in general it is inconvenient or event not possible for systems to decide if information has to be inserted or updated, syngo.share treats HL7 messages which insert or update information depending on the existence of the underlying objects (for example patients, visits, orders, etc.). That means, if a HL7 message is received by syngo.share which should insert an object that already exists, the information of the object is updated. Vice versa if a HL7 message is received by syngo.share which should update the information of an unknown object, the corresponding object is inserted.
2 XX0 Xxxxxxx Interface
2.1 Patient and Visit Administration
The primary goal of the HL7 interface is the synchronization of patient and visit information. For this purpose syngo.share provides an interface which allows the third-party system that manages the patient and visit base (e.g., HIS or RIS) to insert, update, delete, and merge patients as well as to insert, update, delete, move, and merge visits by sending HL7 ADT messages. Each HL7 ADT message has to be dedicated to exactly one patient and mostly one visit. Since syngo.share does not support visits on account level it is assumed that visit information always specify a visit on visit level (cf. HL7 Messaging Standard).
Within syngo.share patients and visits are not just inserted via HL7 ADT messages. If a DICOM Image or generic file is archived and the corresponding patient or visit does not exist, a new patient or visit is inserted. Similarly, if an order is inserted via a HL7 OMI or HL7 ORM message but the addressed patient or visit is unknown, it is inserted (see Section 2.2). Since the patient and visit information associated with DICOM Images or generic files usually do not come directly from the third-party system which manages the patient and visit base, such information is of lower quality as if it would have been provided by HL7 ADT or HL7 ORM messages. Now to preserve the origin of a patient and visit as well as to prevent that high-quality information can be overwritten by low-quality information, patient and visit information are flagged as high-quality or low-quality information. Any patient or visit that has been inserted during the processing of a XX0 XXX, XX0 XXX, or HL7 ORM message is marked to be of high-quality. Patients and visits which have been inserted during import processes are flagged as low-quality patients and visits.
High-quality patients are identified by a patient ID whereas each low-quality patient is identified by a so called identification tuple consisting of a patient ID as well as the last name, first name, birth timestamp, and sex of the patient. The reason for the quite complex identification of low-quality patients is related to the fact that patient IDs of low-quality patients need not be correct. So to avoid that low-quality patients accidentally overwrite each other, the mentioned identification tuple is used to identify low-quality pa- tients uniquely. In case of visits the situation is much simpler. Since visits can be identified just by a visit ID, both high-quality visits and low-quality visits are identified equally.
XX0 Xxxxxxx Interface
To insert, update, delete, and merge patients syngo.share sticks to the rules proposed by the HL7 Mes- saging Standard. That means, if a patient should be inserted or updated it is first checked if a high-quality patient with the specified patient ID or a low-quality patient with the defined identification tuple exists. If no patient is found, a high-quality patient with the information specified by the HL7 ADT message is inserted. If a high-quality patient is found it is first checked if the last name, first name, birth timestamp, or sex of the patient will be changed. If that is the case the found patient is invalidated by a newly inserted patient which represents an updated version of the found patient. If a low-quality patient is found it is updated and transformed into a high-quality patient. An invalidation tree is not constructed. If a patient has to be deleted it is first checked if the patient exists (remember that high-quality patients are iden- tified by the specified patient IDs whereas low-quality patients are identified by the given identification tuples). If it exists it is deleted. Otherwise the HL7 ADT message is ignored. Finally, if two patients have to be merged it is first checked if the new patient exists. If that is the case the found patient is updated and transformed into a high-quality patient if needed. Otherwise an appropriate high-quality patient is inserted. Afterwards it is checked if the old patient exists. If that is the case the old patient is invalidated by the new patient to maintain a possibly existing invalidation tree.
To insert, update, delete, move, and merge visits syngo.share proceeds as follows: If a visit should be inserted or updated it is first checked if a high-quality or low-quality visit with the specified visit ID exists. If no visit is found, a high-quality visit with the information specified by the HL7 ADT message is inserted. Otherwise the found visit is updated and transformed into a high-quality visit. If a visit has to be deleted it is first checked if it exists (remember that high-quality and low-quality visits are identified by the stated visit IDs). If it exists it is deleted. Otherwise the HL7 ADT message is ignored. If a visit has to be moved from one patient to another patient it is first checked if the visit exists. If that is not the case, a high-quality visit belonging to the requested patient is inserted. Otherwise the found visit is updated, transformed into a high-quality visit if needed, and moved to the requested patient. Finally, if two visits have to be merged it is first checked if the new visit exists. If that is the case the found visit is updated and transformed into a high-quality visit if needed. Otherwise an appropriate high-quality visit is inserted. Afterwards it is checked if the old visit exists. If that is the case the old visit is invalidated by the new visit to maintain a possibly existing invalidation tree.
Note that the reason for the construction of invalidation trees can be traced back to the fact that patient and visit information of DICOM Images and generic files might have become obsolete when they are archived by syngo.share. So if a DICOM Image or generic file consists of old patient (visit) information, syngo.share tries to find a patient (visit) by searching for an invalidated patient (visit) with the given identification tuple (visit ID). If that succeeds the DICOM Image or generic file is assigned to the correct patient (visit) without further ado.
2.1.2 HL7 ADT Message Structure
To administrate patients and visits via HL7 ADT messages syngo.share supports the trigger events A01
to A04, A06 to A08, A11 to X00, X00, X00, X00, X00, X00, X00, X00, X00, X00, X00, and A50. Other trigger
events associated with HL7 ADT messages are currently not supported by syngo.share. The trigger events X00, X00, X00, X00, X00, and A13 are used to insert or update a patient and visit. So a HL7 ADT message associated with one of these trigger events has to comply with the following structure:
MSH PID [NK1] PV1 [ROL] [GT1]
The trigger events A06 and A07 are used to insert or update a patient and visit. If a HL7 MRG segment is defined, the specified visit is merged with the visit specified by the HL7 PV1 segment. The structure of such a HL7 ADT message looks as follows:
MSH PID [MRG] [NK1] PV1 [ROL] [GT1]
With the trigger events A08, A28, and A31 it is possible to insert or update a patient without specifying any visit. However, if a visit is present it is inserted or updated. So each HL7 ADT message associated with one of these trigger events has to meet the following structure:
MSH PID [NK1] [PV1] [ROL] [GT1]
A HL7 ADT message equipped with the trigger event A11 or A23 deletes a visit. To this end it has to provide the following information:
MSH PID PV1
XX0 Xxxxxxx Interface
Next, the trigger events X00, X00, xxx X00 should be used in combination with a HL7 ADT message which merges two patients. Hence it has to specify the following HL7 segments:
MSH PID MRG [NK1] [GT1]
A HL7 ADT message that specifies the trigger event A29 deletes a patient. The structure of such a HL7 ADT message looks as follows:
MSH PID
The trigger event A42 is used to merge a visit. If the patient associated with the new visit does not exist it is created. Otherwise it is updated. Each HL7 ADT message associated with this trigger event has to meet the following structure:
MSH PID MRG [NK1] PV1 [ROL] [GT1]
The trigger event A45 is used to move a visit specified by the HL7 MRG segment. If the patient specified by the HL7 ADT message does not exist it is created. Otherwise it is updated. Furthermore if the HL7 ADT message specifies a visit via a HL7 PV1 segment, the moved visit is updated if the two visit IDs are identical. Otherwise the moved visit is merged with the new visit specified by the HL7 PV1 segment. Note that the new visit is created if it does not exist. The structure of such a HL7 ADT message looks as follows:
MSH PID MRG [NK1] [PV1] [ROL] [GT1]
A HL7 ADT message based on the trigger event A47 updates the patient ID of a patient. To perform this operation syngo.share invalidates the old patient by a newly created patient which represents an updated version of the old patient. HL7 ADT messages of this type have to provide the following information:
MSH PID MRG [NK1] [GT1]
Finally, the trigger event A50 is used to replace the visit ID of a visit. To guarantee a consistent construction of invalidation trees syngo.share invalidates the old visit by a newly created visit which represents an updated version of the old visit. Each HL7 ADT message associated with this trigger event has to comply with the following structure:
MSH PID MRG [NK1] PV1 [ROL] [GT1]
Independent from the used trigger event, the patient ID of the given patient has to be specified by the HL7 component PID-3.1 whereas the visit ID has to be defined by the HL7 component PV1-19.1. The specification of a HL7 ROL, HL7 NK1, and HL7 GT1 segment is possible whenever the used trigger event might cause the insertion or update of the stated patient or visit although the HL7 ROL, HL7 NK1, and HL7 GT1 segment might not be part of the official structures defined by the HL7 Messaging Standard.
The HL7 inbound interface of syngo.share allows third-party systems (e.g., HIS or RIS) to insert, update, and delete orders, requested procedures, and scheduled procedure steps by sending HL7 OMI and HL7 ORM messages. Each HL7 OMI message must be dedicated to exactly one order whereas a HL7 ORM mes- sages has to focus on a particular requested procedure of an order. Since HL7 OMI messages represent the state of the art and facilitate a more compact and simpler specification of orders, requested proce- dures, and scheduled procedure steps than HL7 ORM messages, they should be preferred. The processing of multiple orders within a HL7 OMI or HL7 ORM message is not supported.
XX0 Xxxxxxx Interface
To identify an order uniquely syngo.share uses either the placer order number or filler order number. Since the filler order number is usually more specific than the placer order number, the filler order num- ber is used to identify an order whenever it is specified. If the filler order number is not given, the placer order number is used. In the remainder of the section we denote the ID used to identify an order as order ID. Each order consists of one or more requested procedures. To associate requested procedures with DICOM Studies syngo.share follows the guidelines proposed by the IHE Radiology Technical Framework. That means, to identify a requested procedure uniquely syngo.share uses the Study Instance UID of the resulting DICOM Study specified by the received HL7 OMI (see HL7 IPC segment) or HL7 ORM message (see HL7 ZDS segment). Finally each requested procedure is again subdivided into one ore more sched- uled procedure steps. To identify a scheduled procedure step uniquely syngo.share uses the so called scheduled procedure step ID.
To insert or update orders, requested procedures, and scheduled procedure steps syngo.share checks at first if an order with the given order ID exists. If that is the case the information of the order are updated. Otherwise the order is created using the information provided by the HL7 OMI or ORM message. If the patient or visit associated with the order does not exist, a high-quality patient or visit is inserted. If the patient or visit exists but is of low-quality, it is updated and transformed into a high-quality patient or visit (see Section 2.1 for detailed information about the handling of patients and visits). Afterwards it is checked for each specified requested procedure if the created or found order possesses a requested pro- cedure with the specified Study Instance UID. If that is the case the corresponding requested procedure is updated. Otherwise it is created. Likewise for each scheduled procedure step it is checked if the dedicated requested procedure consists of a scheduled procedure step with the stated scheduled procedure step ID. If that is the case the corresponding scheduled procedure step is updated. Otherwise it is created.
If syngo.share receives a HL7 OMI or HL7 ORM message which requires the deletion of an order it is checked if the order exists using the specified order ID (remember that the order ID either refers to the filler order number or placer order number). If the order exists it is deleted inclusive all associated requested procedures and scheduled procedure steps. Otherwise the HL7 OMI or HL7 ORM message is ignored. Note that it is not possible to delete single requested procedures or scheduled procedure steps with HL7 OMI or HL7 ORM messages.
To synchronize requested procedures and DICOM Studies syngo.share provides the possibility to set up a so called metadata update (see also the System Documentation of syngo.share). In this particular case syngo.share checks, whenever a requested procedure is inserted or updated by a HL7 OMI or HL7 ORM message, if the addressed DICOM Study already exists. If that is the case, at first the metadata of the existing DICOM Study is synchronized by modifying the values of the following DICOM Tags:
AccessionNumber (0008,0050): updated via the HL7 component IPC-1.1 in case of a HL7 OMI message or the HL7 field OBR-18 in case of a HL7 ORM message
ReferringPhysiciansName (0008,0090): updated via the HL7 field PV1-8 StudyDescription (0008,1030): updated via the HL7 component OBR-44.5
RequestedProcedureID (0040,1001): updated via the HL7 component IPC-2.1 in case of a HL7 OMI message or the HL7 field OBR-19 in case of a HL7 ORM message
Afterwards the existing DICOM Study is reallocated to the patient and visit associated with the order, if necessary. This guarantees that corrective workflows based on orders, as defined by the IHE Radiology Technical Framework, succeed independent from the quality of the involved patients and visits.
XX0 Xxxxxxx Interface
Another feature of syngo.share which is connected to the administration of orders is the providing of DICOM worklists. For this purpose syngo.share holds a DICOM worklist for each scheduled station AET that has been addressed by at least one HL7 OMI or HL7 ORM message. If a HL7 OMI or HL7 ORM message specifies an order that has been scheduled for processing its scheduled procedure steps are put on the worklists of the assigned scheduled station AETs. A scheduled procedure step is removed from a DICOM worklist if the corresponding DICOM Study has been archived or the associated order has been marked as completed by updating the status of the order via a HL7 OMI or HL7 ORM message. In the former case the Study Instance UID and scheduled procedure step IDs of the DICOM Study are used to identify affected scheduled procedure steps. In the latter case all scheduled procedure steps of the order are removed from the worklist. Further information about worklists can be obtained from the System Documentation of syngo.share as well as the DICOM Conformance Statement.
2.2.2 HL7 OMI Message Structure
To insert, update, and delete orders, requested procedures, and scheduled procedure steps via HL7 OMI messages syngo.share supports the trigger event O23 as proposed by the HL7 Messaging Standard. Other trigger events associated with HL7 OMI messages are neither supported by the HL7 Messaging Standard
nor by syngo.share. To ensure that syngo.share can process HL7 OMI messages they have to meet the following structure:
MSH PID [NK1] [PV1] [ROL] [GT1] {ORC TQ1 OBR {IPC}}
To distinguish between HL7 OMI messages which insert, update, and delete orders, requested procedures, and scheduled procedure steps syngo.share relies on the valid specification of the HL7 field ORC-1. To insert an order, requested procedure, or scheduled procedure step this HL7 field has to specify the value NW. The values XO or DC have to be used if an order, requested procedure, or scheduled procedure step should be updated (note that XO indicates an ordinary modification of an order, requested procedure, or scheduled procedure step whereas DC announces the discontinuation of an order, requested procedure, and scheduled procedure step). If an order has to be deleted the value CA has to be defined by the HL7 field ORC-1. If syngo.share is used to provide DICOM worklists the HL7 field ORC-5 has to define the value SC in order to guarantee that the listed scheduled procedure steps are scheduled for processing. To mark an order as completed and hence to remove all scheduled procedure steps from worklists, ORC-5 has to state the value CM. The placer order number and filler order number which are used by syngo.share to identify an order uniquely have to be specified by the HL7 components OBR-2.1 and OBR-3.1 as well as ORC-2.1 and ORC-3.1. The Study Instance UID which is used to identify a requested procedure uniquely has to be specified by the HL7 component IPC-3.1. Likewise the HL7 component IPC-4.1 has to define for each scheduled procedure step a unique scheduled procedure step ID. The scheduled station AET associated with each scheduled procedure step must be defined by the HL7 field IPC-9. Note that each HL7 OMI message is dedicated to exactly one order. To define more than one requested procedure, the HL7 ORC/ TQ1/OBR/IPC segment group has to be repeated appropriately often. Furthermore to divide a requested procedure into multiple scheduled procedure steps the HL7 IPC segment has to be repeated suitable often within the corresponding XX0 XXX/XX0/XXX/XXX segment group. If more than one requested procedure (scheduled procedure step) is defined, it has to be guaranteed that information related to the order (order and requested procedure) do not vary. Beside that the HL7 PV1 segment should be present if and only if the underlying order belongs to a visit. Furthermore, the specification of a HL7 ROL and XX0 XX0 segment is possible although it is not part of the official structure defined by the HL7 Messaging Standard.
2.2.3 HL7 ORM Message Structure
To insert, update, and delete orders, requested procedures, and scheduled procedure steps via HL7 ORM messages syngo.share supports the trigger event O01 as proposed by the HL7 Messaging Standard. Other trigger events associated with HL7 ORM messages are neither supported by the HL7 Messaging Standard nor by syngo.share. To ensure that syngo.share can process HL7 ORM messages they have to meet the following structure:
MSH PID [NK1] [PV1] [ROL] [GT1] {ORC OBR} ZDS
XX0 Xxxxxxx Interface
To distinguish between HL7 ORM messages which insert, update, and delete orders, requested proce- dures, and scheduled procedure steps syngo.share relies on the valid specification of the HL7 field ORC-1. To insert an order, requested procedure, or scheduled procedure step this HL7 field has to specify the value NW. The values XO or DC have to be used if an order, requested procedure, or scheduled procedure step should be updated (note that XO indicates an ordinary modification of an order, requested procedure, or scheduled procedure step whereas DC announces the discontinuation of an order, requested procedure, and scheduled procedure step). If an order has to be deleted the value CA has to be defined by the HL7 field ORC-1. If syngo.share is used to provide DICOM worklists the HL7 field ORC-5 has to define the value SC in order to guarantee that the listed scheduled procedure steps are scheduled for processing. To mark an order as completed and hence to remove all scheduled procedure steps from worklists, ORC-5 has to state the value CM. The placer order number and filler order number which are used by syngo.share to identify an order uniquely have to be specified by the HL7 components OBR-2.1 and OBR-3.1 as well as ORC-2.1 and ORC-3.1. The Study Instance UID which is used to identify a requested procedure uniquely has to be specified by the HL7 component ZDS-1.1. Likewise the HL7 field OBR-20 has to define for each
scheduled procedure step a unique scheduled procedure step ID. The scheduled station AET associated with each scheduled procedure step must be defined by the HL7 field OBR-21. Note that each HL7 ORM message is dedicated to exactly one requested procedure. To define more than one scheduled procedure step, the XX0 XXX/XXX segment group has to be repeated appropriately often. However, in this particular case it is important that information related to the order and requested procedure do not vary. Beside that the HL7 PV1 segment should be present if and only if the underlying order belongs to a visit. Fur- thermore, the specification of a HL7 ROL and XX0 XX0 segment is possible although it is not part of the official structure defined by the HL7 Messaging Standard.
2.3 Archiving of Generic Files
To archive generic files various interfaces are provided by syngo.share (cf. System Documentation of syngo.share). The most frequently used interface is based on the HL7 Messaging Standard. To archive generic files via the HL7 interface both HL7 MDM and HL7 ORU messages can be used. However, it is strictly recommended to use HL7 MDM messages instead of HL7 ORU messages because the use of HL7 MDM messages is favored by the HL7 Messaging Standard since they allow a more fine-grained specifi- cation of generic files. In addition some functionalities like the XDS registration of a generic file in an affinity domain rely on metadata which can only be specified by a HL7 MDM message.
In general all possible types of generic files can be archived. To allow third-party systems to synchronize their data with syngo.share it is possible to insert, update, and delete generic files. Each HL7 MDM and HL7 ORU message must be dedicated to exactly one generic file. The binary data of a generic file can be transmitted by reference or by value. In the former case the generic file has to be written to a share and referenced via an UNC-path which meets the following format:
Windows: \\<host>\<share>\<path> Linux: //<host>/<share>/<path>
In the latter case the binary data has to be encapsulated in the HL7 MDM or HL7 ORU message. Since it is not allowed to transmit non-printable characters within a HL7 message, it is necessary to encode the binary data so that the sent HL7 MDM or HL7 ORU message is syntactically correct and hence can be parsed by syngo.share. Actually, syngo.share supports the following encodings:
A: The binary data is encoded as a HL7 escaped string.
Base64: The binary data is Base64 encoded. It is recommended to ignore the maximum line length of 76 characters required by RFC 2045. If not, line breaks have to be HL7 escaped.
Hex: The binary data has to be encoded as a hexadecimal string.
UU: The binary data has to be uu encoded. Note that non-printable characters have to be HL7 es- caped.
XX0 Xxxxxxx Interface
To identify a generic file uniquely syngo.share uses two IDs: a generic file ID and an application ID. The ap- plication ID is needed to identify the third-party system that archives the generic file whereas the generic file ID is used to identify the generic file among the generic files inserted by the sending third-party sys- tem. Each generic file is archived in syngo.share within a so called generic container. Generic containers are used to group generic files. They are identified by a generic container ID and a coding system ID. Since a generic container might be reused for patients and shared between third-party systems the combina- tion of generic container ID and coding system ID need not be unique. However, to ensure that generic containers can be used in a meaningful way it is is guaranteed by syngo.share that a patient does not possess two generic containers with identical generic container ID and coding system ID with regard to
a certain visit and organizational unit. So the integration of a generic file into a generic container takes places with respect to the associated patient, visit, and organizational unit.
The approach used by syngo.share to insert or update a generic file depends on the type of the HL7 message. If a generic file should be updated via a HL7 MDM message, according to the HL7 Messag- ing Standard, a new generic file ID should be generated which is linked to the original generic file by specifying the old generic file ID. Since the generation of a new generic file ID might not be possible or inconvenient, syngo.share supports the update of generic files without changing the generic file ID. Now to insert or update a generic file via a HL7 MDM message syngo.share primarily checks if a generic file with the specified new generic file ID and application ID or old generic file ID and application ID already exists. If neither the new generic file ID nor the old generic file ID (might be undefined) yields a generic file archived by syngo.share the generic file is stored based on the patient, visit, and organizational unit information specified by the HL7 MDM message. If the patient or visit does not exist, a low-quality pa- tient or visit is inserted. An update of an existing patient or visit is not performed (see Section 2.1 for detailed information about the handling of patients and visits). If the old generic file ID and application ID references a generic file stored by syngo.share but the new generic file ID and application ID does not, the metadata of the generic file identified by the old generic file ID and application ID are updated and the old generic file ID is replaced by the new generic file ID. If the binary data of the generic file changed too, a new version of the generic file is stored. If the new generic file ID and application ID addresses a generic file archived by syngo.share but the old generic file (might be undefined) and application ID does not, the generic file identified by the new generic file ID and application ID is updated (metadata and binary data if present). If both, the new generic file ID and application ID as well as the old generic file ID and application ID refer to a generic file archived by syngo.share an error is reported if the new generic file ID and the old generic file ID are different. If the generic file IDs are identical, the metadata of the found generic file is updated without changing the generic file ID. Furthermore if the binary data of the generic file changed too, a new version of the generic file is archived.
The processing of HL7 ORU messages which insert or update generic files is much easier than the one of HL7 MDM messages because generic file IDs cannot be changed via HL7 ORU messages. So to insert or update a generic file via a HL7 ORU message syngo.share primarily checks if a generic file with the specified generic file ID and application ID already exists. If that is not the case, the generic file is archived based on the patient, visit, and organizational unit information specified by the HL7 ORU message. If the patient or visit does not exist, a low-quality patient or visit is inserted. An update of an existing patient or visit is not performed (see Section 2.1 for detailed information about the handling of patients and visits). If the generic file exists, the metadata of the generic file are updated. If the binary data of the generic file changed too, a new version of the generic file is stored. Note, if a generic file is updated via a HL7 MDM or HL7 ORU message any specified patient, visit, and organizational unit information are ignored.
The approach used by syngo.share to delete generic files is independent form the type of the HL7 message. To delete a generic file syngo.share simply checks if a generic file with the specified generic file ID and application ID exists. If that is the case the corresponding generic file is deleted. Afterwards it is checked if the generic container, to which the generic file belongs, just consists of deleted generic files. If that is the case the generic container is deleted too. If the generic file, which should be deleted, does not exist, syngo.share ignores the sent HL7 MDM or HL7 ORU message.
HL7 Inbound Interface
2.3.2 HL7 MDM Message Structure
To insert, update, and delete generic files via HL7 MDM messages syngo.share supports the trigger events T02, T09, T10, and T11. Other trigger events associated with HL7 MDM messages are currently not sup- ported by syngo.share. The trigger event T02 is used to insert a generic file, T09 is used to update the metadata of a generic file, T10 is used to update the metadata and binary data of a generic file, and T11 is used to delete a generic file. To ensure that syngo.share can process HL7 MDM messages associated with trigger events T02 and T10 these HL7 messages have to comply with the following structure:
MSH PID [NK1] [PV1] [ROL] [GT1] [OBR] TXA OBX
The structure of HL7 MDM messages associated with trigger events T09 and T11 is a little bit simpler because they do not provide any binary data. On this account it is not necessary to specify any HL7 OBX segment. So the structure of such HL7 MDM messages looks as follows:
MSH PID [NK1] [PV1] [ROL] [GT1] [OBR] TXA [OBX]
Independent from the used trigger event the generic file ID has to be specified by the HL7 component TXA-12.1. The application ID has to be defined by the HL7 field MSH-3 whereby the HL7 component MSH-3.1 is evaluated if it is specified and the HL7 component MSH-3.2 is used if MSH-3.1 has been left empty. The generic container ID and the coding system ID have to be defined by the HL7 components TXA-24.1 and TXA-24.3. Note that in case of HL7 ORU messages the generic file ID, generic container ID, and coding system ID are specified by different HL7 components. It also has to be taken into account that the HL7 PV1 segment should be present if and only if the underlying generic file belongs to a visit. The specification of a HL7 ROL, HL7 NK1, and HL7 GT1 segment is possible although they are not part of the official structure defined by the HL7 Messaging Standard. The same applies to the HL7 OBX segment in case of HL7 MDM messages associated with the trigger event T09 — although it is not part of the official structure defined by the HL7 Messaging Standard it can be specified in order to update metadata. Besides that it must be pointed out that syngo.share supports the specification of at most one HL7 OBR segment. The specification of a HL7 ORC segment, as requested by the HL7 Messaging Standard, is not necessary. Furthermore, in accordance with the HL7 Messaging Standard it is not allowed to transmit the binary data of a generic file in a HL7 MDM message based on the trigger event T02 or T10 using more than one HL7 OBX segment.
2.3.3 HL7 ORU Message Structure
To insert, update, and delete generic files via HL7 ORU messages syngo.share supports the trigger event R01 as proposed by the HL7 Messaging Standard. Other trigger events associated with HL7 ORU messages are not supported by syngo.share. To ensure that syngo.share can process HL7 ORU messages within this context they have to meet the following structure:
MSH PID [NK1] [PV1] [ROL] [GT1] [OBR] OBX
XX0 Xxxxxxx Interface
To distinguish between HL7 ORU messages which insert or update generic files and HL7 ORU messages which delete generic files syngo.share relies on the valid specification of the HL7 fields OBR-25 and OBX-11. In order to insert or update a generic file the two HL7 fields have to be specify the value F. If a generic file should be deleted, a D has to be stated. Because HL7 ORU messages do not possess HL7 TXA segments the IDs used to identify generic files and generic containers are defined by other HL7 components than in case of HL7 MDM messages. Especially, the generic file ID has to be defined by the HL7 component OBX-3.1 and the generic container ID and the coding system ID have to be defined by the HL7 components OBX-3.4 and OBX-3.6. The application ID has to be defined by the HL7 field MSH-3, similarly as in case of HL7 MDM messages. Note that the HL7 PV1 segment should be present if and only if the underlying generic file belongs to a visit. The specification of a HL7 ROL and HL7 GT1 segment is possible although it is not part of the official structure defined by the HL7 Messaging Standard. Besides that it must be pointed out that syngo.share supports the specification of at most one HL7 OBR segment. The specification of a HL7 ORC segment is not necessary. Furthermore, in accordance with the HL7 Messaging Standard it is not allowed to transmit the binary data of a generic file using more than one HL7 OBX segment.
2.4 Sharing of DICOM Studies and Generic Containers
Via the HL7 inbound interface it is possible to share DICOM Studies and generic containers so that they can be accessed via the module webbox by designated users. To share DICOM Studies and generic con- tainers HL7 ORU messages have to be used. To allow third-party systems to administrate shares of DICOM Studies and generic containers it is possible to create and delete shares. Each HL7 ORU message has to be dedicated to exactly one DICOM Study or generic container. The number of users for which a share should be created or deleted is not restricted. Since each share allows exactly one user to access a specific DICOM Study or generic container, each HL7 ORM message has to specify for all listed users if a share with respect to the referenced DICOM Study or generic container should be created or an existing share for the given DICOM Study or generic container should be deleted. So, with one HL7 ORU message it is possible to create and delete shares. To ensure that syngo.share can identify the DICOM Study or generic container which should be shared or for which a share should be deleted uniquely, the reference pointer of the DI- COM Study or generic container has to be specified. Note that reference pointers can be obtained from syngo.share automatically via HL7 ORU messages (see Section 3.2 for further information). To identify a user syngo.share expects that the login name of the user is stated.
2.4.2 HL7 ORU Message Structure
To administrate DICOM Study and generic container shares via HL7 ORU messages syngo.share supports the trigger event R01. So based on this fact the transmitted HL7 ORU messages have to meet the following structure:
MSH OBX {PRT}
To distinguish between shares that have to be created for a DICOM Study or generic container and shares which should be deleted, syngo.share relies on the valid specification of the HL7 field PRT-2. In order to share a DICOM Study or generic container PRT-2 has to specify the value LI. If an existing share should be deleted, the value UN has to be stated. The reference pointer which identifies the DICOM Study or generic container that should be shared has to be specified by the HL7 component OBX-5.1. The login name of the user has to be defined by the HL7 component PRT-1.1. Note, to specify more than one user the HL7 PRT segment has to be repeated appropriately often.
2.5 Deletion of DICOM Studies and Generic Containers
XX0 Xxxxxxx Interface
Via the HL7 inbound interface it is possible to delete DICOM Studies and generic containers. Since this way of deletion is not standardized it is recommended to use KOS Rejection Notes to delete DICOM Images (see the syngo.share of DICOM Conformance Statement) and HL7 MDM or HL7 ORU messages, as specified by Section 2.3, to delete generic files. If the standardized deletion is out of the question, HL7 ORU messages can be used to delete DICOM Studies and generic containers. Thereby each HL7 ORU message must be dedicated to exactly one DICOM Study or generic container. To ensure that syngo.share can identify the DICOM Study or generic container which should be deleted uniquely, the reference pointer of the DICOM Study or generic container has to be specified. Note that reference pointers can be obtained from syngo.share automatically via HL7 ORU messages (see Section 3.2 for further information).
2.5.2 HL7 ORU Message Structure
To delete DICOM Studies and generic containers via HL7 ORU messages syngo.share supports the trigger event R01. Based on this fact the transmitted HL7 ORU messages have to meet the following structure:
MSH OBX
The reference pointer which identifies the DICOM Study or generic container that should be deleted has to be specified by the HL7 component OBX-5.1.
The HL7 MSH segment of an incoming HL7 message has to provide the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 Field Separator | R | ||
2 | Encoding Characters | R | ||
3.1 | Sending Application Namespace ID | 64 | C | |
3.2 | Sending Application Universal ID | 64 | C | |
4.1 | Sending Facility Namespace ID | 50 | C | |
4.2 | Sending Facility Universal ID | 50 | C | |
5.1 | Receiving Application Namespace ID | O | ||
5.2 | Receiving Application Universal ID | O | ||
6.1 | Receiving Facility Namespace ID | 100 | C | |
6.2 | Receiving Facility Universal ID | 100 | C | |
7 | HL7 Message Timestamp | O | ||
9.1 | HL7 Message Code | R | ||
9.2 | HL7 Message Trigger Event | R | ||
9.3 | HL7 Message Structure | O | ||
10 | HL7 Message Control ID | R | ||
11.1 | Processing ID | O | ||
12.1 | Version ID | O | ||
13 | HL7 Message Sequence Number | O | ||
15 | Accept Acknowledgment Type | C | ||
16 | Application Acknowledgment Type | C | ||
18 | Character Set | C | yes | |
20 | Alternate Character Set Handling Scheme | C |
HL7 Inbound Interface
The HL7 components MSH-3.1 and MSH-3.2 have to define the sending application of the HL7 message uniquely. It is required by syngo.share that at least one of the two HL7 components is specified. If MSH-3.1 is left empty the value of MSH-3.2 is taken to identify the sending application. In all other cases MSH-3.1 is evaluated. Note to insert, update, or delete a generic file the determined sending application is used as application ID to identify the third-party system that is responsible for the generic file uniquely (cf. Section 2.3). The HL7 components MSH-4.1 and MSH-4.2 are used to identify the sending facility of the HL7 message. It is required that at least one of the two HL7 components is specified because syngo.share uses this information to identify the organizational unit that is affected by the HL7 message. If MSH-4.1
is left empty the value of MSH-4.2 is taken to retrieve the organizational unit. In all other cases MSH-4.1 is evaluated. The receiving application (HL7 components MSH-5.1 and MSH-5.2) is evaluated in a similar vein as the sending application. Since the processing of a HL7 messages does not rely on this information, it need not be specified. The HL7 components MSH-6.1 and MSH-6.2 are used to obtain the receiving facility of the HL7 message which again is used by syngo.share to identify the tenant that is affected by the HL7 message. The HL7 components MSH-6.1 and MSH-6.2 are evaluated in a similar way as the sending facility. This means if MSH-6.1 is not specified MSH-6.2 has to define the receiving facility. The HL7 fields MSH-15 and MSH-16 define on the one hand the processing rules that have to be applied to exchange the HL7 message and on the other hand the conditions under which a HL7 accept acknowledgment message and HL7 application acknowledgment message have to be sent if the enhanced processing rules are in effect. To ensure that the original processing rules are used, both HL7 fields have to be left empty. If the enhanced processing rules should be applied, at least one of the two HL7 fields has to be defined. Last but not least the character sets which have been used to generate the HL7 message have to be specified by the HL7 field MSH-18. If more than on character set is in use, the handling scheme of the alternate character sets has to be defined by the HL7 field MSH-20. For possible values of MSH-18 and MSH-20 confer Section 1.1.
The HL7 PID segment of an incoming HL7 message has to provide the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 PID Segment ID | O | ||
3.1 | Patient ID | 50 | R | yes |
3.4 | Patient ID Assigning Authority | 50 | O | |
3.5 | Patient ID Type | R | ||
5.1 | Patient Last Name | 64 | O | yes |
5.2 | Patient First Name | 64 | O | |
5.3 | Patient Middle Name | 64 | O | |
5.4 | Patient Name Suffix | 64 | O | |
5.5 | Patient Name Prefix | 64 | O | |
5.8 | Patient Name Representation | C | ||
6 | Mothers Maiden Name | 150 | O | |
7 | Patient Birth Timestamp | 24 | O | |
8.1 | Patient Sex | 1 | O | |
10 | Patient Race | 50 | O | |
11 | Patient Address | 350 | O | |
16 | Patient Marital Status | 50 | O | |
17 | Patient Religion | 20 | O | |
18 | Patient Account Number | 250 | O | |
23 | Patient Birth Place | 350 | O | |
24 | Multiple Birth Indicator | 1 | O | |
26 | Patient Citizenship | 50 | O | |
27 | Patient Profession | 100 | O | |
29 | Patient Death Timestamp | 24 | O | |
40 | Patient Telecommunication Information | 200 | O |
XX0 Xxxxxxx Interface
The HL7 field PID-1 should specify the value 1 (note that syngo.share cannot process more than one HL7 PID segment). The HL7 components PID-3.1 and PID-3.5 have to be used to specify the patient ID as
well as alternate patient ID of the patient addressed by the HL7 PID segment. The specification of the patient ID is obligatory whereas the specification of an alternate patient ID is optional. To differ between the two IDs, the HL7 component PID-3.5 has to specify the value PI or PN if PID-3.1 defines the patient ID and the value NH, NI, or SS if PID-3.1 specifies an alternate patient ID. Note that the value NH indicates that the alternate patient ID represents a unique national identifier, NH states that the alternate patient ID defines a national health service number, and SS denotes that the alternate patient ID identifies a social security number. The assigning authority of the patient ID and alternate patient ID has to be defined by the HL7 component PID-3.4 whereby the HL7 subcomponent PID-3.4.1 is evaluated if it is specified and the HL7 subcomponent PID-3.4.2 is used if PID-3.4.1 has been left empty. The HL7 components PID-5.1 to PID-5.8 are evaluated to obtain the names of the patient. Because syngo.share is able to store the alphabetic, ideographic, and phonetic name of a patient, the HL7 component PID-5.8 has to specify an A in the first case, an I for the ideographic name of the patient, and a P if the phonetic name of the patient is given.
The HL7 MRG segment of an incoming HL7 ADT message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1.1 | Prior Patient ID | C | ||
1.4 | Prior Patient ID Assigning Authority | O | ||
1.5 | Prior Patient ID Type | C | ||
5.1 | Prior Visit ID | C | ||
5.4 | Prior Visit ID Assigning Authority | O |
If a HL7 MRG segment is used to merge a patient, the HL7 component MRG-1.1 has to define the patient ID of the patient that should be invalidated. Furthermore the HL7 component MRG-1.5 has to specify the value PI or PN to ensure that syngo.share detects the patient ID. If a HL7 MRG segment is used to move or merge a visit, the HL7 component MRG-5.1 has to specify the visit ID of the visit that should be moved or invalidated. The assigning authority of the prior patient ID (prior visit ID) has to be defined by the HL7 component MRG-1.4 (MRG-5.4) whereby the HL7 subcomponent MRG-1.4.1 (MRG-5.4.1) is evaluated if it is specified and the HL7 subcomponent MRG-1.4.2 (MRG-5.4.2) is used if MRG-1.4.1 (MRG-5.4.1) has been left empty.
HL7 Inbound Interface
The HL7 NK1 segment of an incoming HL7 message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 NK1 Segment ID | O | ||
2 | Next of Kin Name | 250 | O | |
3 | Relationship | 50 | O | |
4 | Next of Kin Address | 350 | O | |
40 | Next of Kin Telecommunication Information | 200 | O |
The HL7 field NK1-1 should specify the value 1 (note that syngo.share cannot process more than one XX0 XX0 segment).
The HL7 PV1 segment of an incoming HL7 message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 PV1 Segment ID | O | ||
2 | Patient Class | 50 | O | |
3 | Assigned Patient Location | 80 | O | |
6 | Prior Patient Location | 80 | O | |
7 | Attending Doctor | 150 | O | |
8 | Referring Doctor | 150 | O | |
9 | Consulting Doctor | 250 | O | |
10 | Hospital Service | 50 | O | |
11 | Temporary Patient Location | 80 | O | |
15 | Ambulatory Status | 50 | O | |
16 | VIP Indicator | 50 | O | |
17 | Admitting Doctor | 150 | O | |
19.1 | Visit ID | 32 | R | |
19.4 | Visit ID Assigning Authority | 50 | O | |
36 | Discharge Disposition | 50 | O | |
37 | Discharge Patient Location | 50 | O | |
39 | Servicing Facility | 100 | O | |
44 | Admit Timestamp | 24 | O | |
45 | Discharge Timestamp | 24 | O | |
50.1 | Alternate Visit ID | 32 | O | |
50.4 | Alternate Visit ID Assigning Authority | 50 | O | |
51.1 | Visit Indicator | O |
The HL7 field PV1-1 should specify the value 1 (note that syngo.share cannot process more than one HL7 PV1 segment). The HL7 field PV1-9 should not be defined. Instead a HL7 ROL segment should be added to the HL7 message which specified the consulting doctor. Nevertheless, if the consulting doctor is defined by the HL7 field PV1-9 but not by a HL7 ROL segment, the HL7 field PV1-9 is still evaluated. The HL7 component PV1-19.1 has to define the visit ID and the HL7 component PV1-51.1 should specify the value V to indicate that the information provided by the HL7 PV1 segment are dedicated to the visit level (note that syngo.share does not support visits related to the account level). The assigning authority of the visit ID (alternate visit ID) has to be defined by the HL7 component PV1-19.4 (PV1-50.4) whereby the HL7 subcomponent PV1-19.4.1 (PV1-50.4.1) is evaluated if it is specified and the HL7 subcomponent PV1-19.4.2 (PV1-50.4.2) is used if PV1-19.4.1 (PV1-50.4.1) has been left empty.
XX0 Xxxxxxx Interface
The HL7 ROL segment of an incoming HL7 message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
2 | Action Code | R | ||
3.1 | Role | R | ||
4 | Person | 250 | O |
The HL7 component ROL-3.1 has to specify the value CP if the HL7 ROL segment states the consulting doctor. In this particular case the HL7 field PV1-9 should not be defined.
The HL7 GT1 segment of an incoming HL7 message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 GT1 Segment ID | O | ||
3 | Guarantor Name | 250 | O | |
5 | Guarantor Address | 350 | O | |
8 | Guarantor Birth Timestamp | 24 | O | |
12 | Guarantor Social Security Number | 50 | O | |
16 | Employer Name | 250 | O | |
17 | Employer Address | 350 | O |
The HL7 field GT1-1 should specify the value 1 (note that syngo.share cannot process more than one HL7 GT1 segment).
In general the information provided by a HL7 ORC segment as well as the structure of a HL7 ORC segment depend on the type of the underlying HL7 message. The HL7 inbound interface of syngo.share just eval- uates HL7 ORC segments in combination with HL7 OMI and HL7 ORM messages. HL7 OMI as well as HL7 ORM messages use HL7 ORC segments to insert, update, and delete orders, requested procedures, and scheduled procedure steps (see Section 2.2). For this purpose each HL7 ORC segment of an incoming HL7 OMI and HL7 ORM message has to provide the following information:
Index | Description | Length | Optionality | Repeatable |
1 | Order Control Code | R | ||
2.1 | Placer Order Number | 199 | C | |
3.1 | Filler Order Number | 199 | C | |
5 | Order Status | 128 | C | |
7.4 | Start Timestamp | 24 | C | |
10 | Order Enterer | 255 | O | |
12 | Order Provider | 255 | O | |
13 | Enterers Location | 80 | O | |
14 | Order Call Back Phone Number | 250 | O | |
16 | Order Control Code Reason | 250 | O | |
17 | Entering Organization | 60 | O | |
21 | Facility | 255 | O |
XX0 Xxxxxxx Interface
The HL7 field ORC-1 determines the function of the order specified by the HL7 ORC segment. Possible values are NW, DC, XO, and CA where NW causes the insertion of the order, DC gives rise to the discontinuation of the order, XO entails the update of the order, and last but not least CA causes the deletion of the order. The HL7 components ORC-2.1 and ORC-3.1 define the placer order number and filler order number of the order and are used by syngo.share to identify it uniquely. So at least one of the two IDs has to be
specified. The HL7 field ORC-5 defines the status of the order. If the scheduled procedure steps of the order have been scheduled for processing the value SC has to be stated. To mark the scheduled procedure steps associated with the order as completed, the value CM has to be used. Finally, in case of a HL7 ORM message the HL7 component ORC-7.4 specifies the start timestamp of the listed scheduled procedure steps. For that reason the specification of the HL7 component ORC-7.4 is mandatory. If the HL7 ORC segment is part of a HL7 OMI message the HL7 component ORC-7.4 should not be specified because the start timestamp of the scheduled procedure steps is defined by a separate XX0 XX0 segment. Note that the HL7 components and HL7 fields ORC-2.1, ORC-3.1, ORC-7.4, ORC-12, and ORC-14 should specify the same values as the HL7 components and HL7 fields OBR-2.1, OBR-3.1, OBR-27.4, OBR-16, and OBR-17 of the associated HL7 OBR segment.
Each HL7 TQ1 segment of an incoming HL7 OMI message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1 | XX0 XX0 Segment ID | O | ||
7 | Start Timestamp | 24 | R |
The HL7 field TQ1-1 should specify a consecutive number (note that HL7 OMI messages might contain more than one HL7 TQ1 segment). The HL7 field TQ1-7 specifies the start timestamp of the scheduled procedure steps that are part of the XX0 XXX/XX0/XXX/XXX segment group to which the HL7 TQ1 segment belongs.
XX0 Xxxxxxx Interface
The information provided by a HL7 OBR segment as well as the structure of a HL7 OBR segment depend, like for a HL7 ORC segment, on the type of the underlying HL7 message. The HL7 inbound interface of syngo.share evaluates HL7 OBR segments in combination with XX0 XXX, XX0 XXX, XX0 XXX, and HL7 ORU messages. HL7 OMI and ORM messages make use of the information provided by HL7 OBR segments to insert and update orders, requested procedures, and scheduled procedures steps (see Section 2.2). Within HL7 MDM and HL7 ORU messages the information provided by HL7 OBR segments is just used for informational purposes (see Section 2.3). Although HL7 OMI and HL7 ORM messages have the same purpose the structure of the used HL7 OBR segments is quite different. Each HL7 OBR segment of an incoming HL7 OMI message has to provide the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 OBR Segment ID | O | ||
2.1 | Placer Order Number | 199 | C | |
3.1 | Filler Order Number | 199 | C | |
4.1 | Universal Service ID | 128 | R | |
4.2 | Universal Service Description | 128 | O | |
12 | Danger Code | 60 | O | |
13 | Relevant Clinical Information | 999 | O | |
15 | Specimen Source | 300 | O | |
16 | Order Provider | 255 | O | |
17 | Order Call Back Phone Number | 250 | O | |
30 | Transportation Mode | 50 | O |
31 | Reason For Study | 300 | O | |
34 | Technician | 200 | O | |
44.1 | Procedure Code | 128 | O | |
44.2 | Procedure Description | 128 | O | |
44.5 | Requested Procedure Description | 128 | O |
The HL7 field OBR-1 should specify a consecutive number (note that HL7 OMI messages might contain more than one HL7 OBR segment). The HL7 components OBR-2.1 and OBR-3.1 have to define the placer order number and filler order number of the order. Since syngo.share uses the two IDs to identify orders, at least one of the two IDs has to be specified. Finally the HL7 component OBR-4.1 specifies the universal service ID — an identifier for the order which usually comes from an industry standard such as SNOMED or LOINC. Note that the HL7 components and HL7 fields XXX-0.0, XXX-0.0, XXX-00, xxx XXX-00 should specify the same values as the HL7 components and HL7 fields ORC-2.1, ORC-3.1, ORC-12, and ORC-14 of the associated HL7 ORC segment.
The HL7 OBR segment of an incoming HL7 ORM message has to provide the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 OBR Segment ID | O | ||
2.1 | Placer Order Number | 199 | C | |
3.1 | Filler Order Number | 199 | C | |
4.1 | Universal Service ID | 128 | R | |
4.2 | Universal Service Description | 128 | O | |
4.4 | Protocol Code | 128 | O | |
4.5 | Protocol Description | 128 | O | |
4.11 | Scheduled Procedure Step Description | 128 | O | |
12 | Danger Code | 60 | O | |
13 | Relevant Clinical Information | 999 | O | |
15 | Specimen Source | 300 | O | |
16 | Order Provider | 255 | O | |
17 | Order Call Back Phone Number | 250 | O | |
18 | Accession Number | 255 | O | |
19 | Requested Procedure ID | 199 | R | |
20 | Scheduled Procedure Step ID | 199 | R | |
21 | Scheduled Station AET | 255 | O | |
24 | Modality | 50 | O | |
27.4 | Start Timestamp | 24 | R | |
30 | Transportation Mode | 50 | O | |
31 | Reason For Study | 300 | O | |
34 | Technician | 200 | O | |
44.1 | Procedure Code | 128 | O | |
44.2 | Procedure Description | 128 | O | |
44.5 | Requested Procedure Description | 128 | O |
HL7 Inbound Interface
The HL7 fields and HL7 components OBR-1, OBR-2.1, OBR-3.1, and OBR-4.1 have to be specified in the same way as described for HL7 OMI messages. The HL7 field OBR-18 is evaluated to obtain the accession number of the order. If the accession number is not specified, syngo.share generates an appropriate ID
automatically. The HL7 field OBR-19 has to specify a unique ID for the requested procedure addressed by the HL7 ORM message. It is used by syngo.share as an alternate unique identifier for the stated requested procedure. Likewise the HL7 field OBR-20 has to define a unique ID for the scheduled procedure step specified by the XX0 XXX/XXX segment group to which the HL7 OBR segment belongs. The HL7 compo- nent OBR-27.4 specifies the start timestamp of the listed scheduled procedure steps. For that reason the specification of the HL7 component ORC-7.4 is mandatory. Note that the HL7 components and HL7 fields XXX-0.0, XXX-0.0, XXX-00.0, XXX-00, xxx XXX-00 should specify the same values as the HL7 components and HL7 fields ORC-2.1, ORC-3.1, ORC-7.4, ORC-12, and ORC-14 of the associated HL7 ORC segment.
If a HL7 OBR segment is part of an incoming HL7 MDM or HL7 ORU message which inserts, updates, or deletes a generic file it has to possess the following structure:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 OBR Segment ID | O | ||
2.1 | Placer Order Number | O | ||
3.1 | Filler Order Number | O | ||
4.1 | Universal Service ID | O | ||
4.2 | Universal Service Description | O | ||
7 | Generic File Creation Timestamp | O | ||
18 | Accession Number | 255 | O | |
24 | Practice Setting Code | 256 | C | |
25 | Result Status | O |
The HL7 field OBR-1 should specify the value 1 (note that HL7 MDM and HL7 ORU messages do not support the processing of more than one HL7 OBR segment). The HL7 field OBR-18 is evaluated to obtain the accession number of the generic file. The HL7 field OBR-24 has to specify the practice setting code of the generic file referenced by the HL7 message. In case of an incoming HL7 MDM message which inserts or updates a generic file the specification of the practice setting code is required if the generic file should be registered in an affinity domain (see IHE IT Infrastructure Technical Framework for further information). To this end the following HL7 components have to be defined:
Index | Description | Length | Optionality |
24.1 | Practice Setting Code ID | 256 | R |
24.2 | Practice Setting Code Display Name | O | |
24.3 | Practice Setting Code Coding Scheme | R |
XX0 Xxxxxxx Interface
In case of HL7 ORU messages the specification of the practice setting code is optional because HL7 ORU messages do not provide enough information to register generic files in affinity domains. The HL7 field OBR-25 indicates the status of the generic file referenced by the HL7 message. If the generic file has been deleted a D should be specified. Otherwise OBR-25 should contain a F. Note that this HL7 field should specify the same value as the HL7 field OBX-11. Furthermore the HL7 field OBR-7 should specify the same value as the HL7 fields TXA-6 and OBX-14 (the specification of the former HL7 field is only possible in conjunction with HL7 MDM messages).
Each HL7 IPC segment of an incoming HL7 OMI message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1.1 | Accession Number | 255 | R |
2.1 | Requested Procedure ID | 199 | R | |
3.1 | Study Instance UID | 255 | R | |
4.1 | Scheduled Procedure Step ID | 199 | R | |
5.1 | Modality | 50 | O | |
6.1 | Protocol Code | 128 | O | |
6.2 | Protocol Description | 128 | O | |
6.5 | Scheduled Procedure Step Description | 128 | O | |
9 | Scheduled Station AET | 255 | O |
The HL7 component IPC-1.1 has to define the accession number of the order. The HL7 component IPC-2.1 has to specify a unique ID for the requested procedure addressed by the XX0 XXX/XX0/XXX/XXX segment group to which the HL7 IPC segment belongs. It is used by syngo.share as an alternate unique identifier for the stated requested procedure. Similarly the HL7 component IPC-3.1 has to define the Study Instance UID of the DICOM Study that should be associated with requested procedure addressed by the underlying XX0 XXX/XX0/XXX/XXX segment group. As mentioned in Section 2.2 the Study Instance UID is used as unique identifier for the affected requested procedure. The HL7 component IPC-4.1 has to define a unique ID for the scheduled procedure step specified by the HL7 IPC segment. Note that syngo.share links the specified scheduled procedure step with the requested procedure addressed by the corresponding XX0 XXX/XX0/XXX/XXX segment group.
The HL7 TXA segment of an incoming HL7 MDM message consists of the following information:
Index | Description | Length | Optionality | Repeatable |
1 | HL7 TXA Segment ID | O | ||
2.1 | Generic File Type ID | 64 | C | |
2.2 | Generic File Type Description | 100 | C | |
2.3 | Generic File Type Coding System ID | 64 | C | |
3 | Generic File Content Presentation | 256 | C | |
6 | Generic File Creation Timestamp | 24 | C | |
9 | Generic File Originator | 1000 | C | |
12.1 | Generic File ID | 256 | R | |
13.1 | Prior Generic File ID | C | ||
16 | Generic Filename | 256 | C | |
17 | Generic File Completion Status | 50 | O | |
18 | Generic File Confidentiality Status | 256 | C | |
22 | Generic File Authenticator | 1000 | C | |
24.1 | Generic Container ID | 256 | R | |
24.2 | Generic Container Description | 250 | O | |
24.3 | Generic Container Coding System ID | 64 | R | |
25 | Generic File Description | 250 | C |
HL7 Inbound Interface
The HL7 field TXA-1 should specify the value 1 (note that syngo.share cannot process more than one HL7 TXA segment). The information stated by the HL7 components TXA-2.1, TXA-2.2, and TXA-2.3 as well as the HL7 fields XXX-0, XXX-0, XXX-00 xxx XXX-00 are primarily needed to register the generic file
specified by the HL7 TXA segment in an affinity domain. In such a case syngo.share requires that TXA-2.1, TXA-2.2, and TXA-2.3 specify the class code, TXA-3 the format code, TXA-9 the author, healthcare facility type code, and institution, TXA-18 the confidentiality code, and TXA-22 the authenticator of the generic file, by providing the following information:
Index | Description | Length | Optionality |
2.1 | Class Code ID | 256 | R |
2.2 | Class Code Display Name | O | |
2.3 | Class Code Coding Scheme | R | |
3.1 | Format Code ID | 256 | R |
3.2 | Format Code Display Name | O | |
3.3 | Format Code Coding Scheme | R | |
9.1 | Originator Person ID | 1000 | O |
9.2 | Originator Last Name | R | |
9.3 | Originator First Name | R | |
9.4 | Originator Middle Name | O | |
9.5 | Originator Name Suffix | O | |
9.6 | Originator Name Prefix | O | |
9.14.1 | Healthcare Facility Type Code ID | R | |
9.14.2 | Healthcare Facility Type Code Display Name | O | |
9.14.3 | Healthcare Facility Type Code Coding Scheme | R | |
9.23.1 | Institution OID | R | |
9.23.2 | Institution Name | R | |
18.1 | Confidentiality Code ID | 256 | C |
18.2 | Confidentiality Display Name | C | |
18.3 | Confidentiality Code Coding Scheme | C | |
22.1 | Authenticator Person ID | 1000 | O |
22.2 | Authenticator Last Name | R | |
22.3 | Authenticator First Name | R | |
22.4 | Authenticator Middle Name | O | |
22.5 | Authenticator Name Suffix | O | |
22.6 | Authenticator Name Prefix | O |
XX0 Xxxxxxx Interface
The HL7 field TXA-6 should always be specified. However syngo.share only requires the specification of the creation timestamp if the generic file has to be registered in an affinity domain. The HL7 component TXA-12.1 has to specify the ID of the referenced generic file which is used together with the application ID, specified by the HL7 component MSH-3.1 or MSH-3.2 (MSH-3.2 is just used if MSH-3.1 is not defined), to identify the generic file uniquely. If the generic file ID is changed, the old generic file ID has to be specified by the HL7 component TXA-13.1 to guarantee that updates can be performed correctly. The name of the generic file (inclusive its file extension) is obtained from the HL7 field TXA-16. Its specification is mandatory if the generic file should be inserted or updated by a new version which possesses a different file extension. The HL7 components TXA-24.1 and TXA-24.3 define the generic container ID and coding system ID of the generic container which contains the generic file. Finally, the HL7 field TXA-25 has to specifies a description of the generic file. If the generic file should be registered in an affinity domain, the specification of TXA-25 is mandatory. Note that the HL7 field TXA-6 should specify the same value as the HL7 fields OBR-7 and OBX-14.