aplicaÇÃo ao sector da saÚde de modelos de boas...

Mapeamento CMMI-SVC e Rastreio do CCR

i Projecto de Dissertação FEUP-ARSN

APLICAÇÃO AO SECTOR DA SAÚDE DE MODELOS DE BOAS PRÁTICAS NA GESTÃO DE SERVIÇOS: CASO DE ESTUDO –

GESTÃO DE RASTREIOS DA ARS NORTE.

Cláudio Vicente Leal Moreira

Anexo à dissertação: Mapeamento CMMI-SVC e Rastreio do CCR

Orientador: Prof. João Pascoal Faria

Faculdade de Engenharia da Universidade do Porto

2011-07-15


ii Projecto de Dissertação FEUP-ARSN


iii Projecto de Dissertação FEUP-ARSN

Índice 1. Introdução ........................................................................................................................................... 1

2. O procedimento ................................................................................................................................... 2

2.1. Classificação – Rating .................................................................................................................. 2

3. Desenvolvimento do Sistema de Serviço - Service System Development (SSD).................................. 4

3.1. SG 1 Develop and Analyze Stakeholder Requirements ............................................................... 5

SP 1.1 Develop Stakeholder Requirements ......................................................................................... 5

SP 1.2 Develop Service System Requirements..................................................................................... 7

SP 1.3 Analyze and Validate Requirements ......................................................................................... 8

3.1.1 Classificação do Objectivo ...................................................................................................... 9

3.2. SG 2 Develop Service Systems .................................................................................................... 9

SP 2.1 Select Service System Solutions ................................................................................................ 9

SP 2.2 Develop the Design ................................................................................................................. 12

SP 2.3 Ensure Interface Compatibility ............................................................................................... 14

SP 2.4 Implement the Service System Design .................................................................................... 16

SP 2.5 Integrate Service System Components ................................................................................... 17

3.2.1 Classificação do Objectivo .................................................................................................... 18

3.3. SG 3 Verify and Validate Service Systems ................................................................................. 18

SP 3.1 Prepare for Verification and Validation .................................................................................. 18

SP 3.2 Perform Peer Reviews ............................................................................................................ 19

SP 3.3 Verify Selected Service System Components .......................................................................... 20

SP 3.4 Validate the Service System .................................................................................................... 21

3.3.1 Classificação do Objectivo .................................................................................................... 21

3.4. Resultado .................................................................................................................................. 21

4. Recomendações ao Desenvolvimento do Sistema de Serviço .......................................................... 25

4.1. Requisitos .................................................................................................................................. 25

4.2. Desenho .................................................................................................................................... 25

4.3. Verificação e Validação ............................................................................................................. 26

4.4. Relação Custo-Benefício ........................................................................................................... 26

5. Recomendações Priorizadas .............................................................................................................. 29

Referências ................................................................................................................................................. 31

Anexo A – Componentes do Sistema de Serviço RCCR............................................................................... 32

Anexo B – Processos Serviço de Rastreio CCR ............................................................................................ 33


iv Projecto de Dissertação FEUP-ARSN

Índice de Figuras e Tabelas

Figura 1. Componentes Modelo CMMI ........................................................................................................ 1

Figura 2. Escala de classificação das práticas tendo por base a escala de fidelidade do SCAMPI C. ............ 3

Figura 3. Peso de cada classificação de EWP ou SB. ..................................................................................... 3

Figura 4. Formula para o cálculo da classificação das práticas ..................................................................... 3

Tabela 1. Template de esquematização das práticas específicas ................................................................. 2

Tabela 2. Escala SCAMPI C (Opcional) .......................................................................................................... 2

Tabela 3. Classificação detalhada de toda a área de processo [12] ........................................................... 22

Tabela 4. Quadro Resumo da Área de Processo......................................................................................... 23

Tabela 5. Recomendações para o desenvolvimento e análise dos requisitos dos stakeholders (SG1) ...... 26

Tabela 6. Recomendações sobre o desenvolvimento do sistema de serviço (SG2) ................................... 27

Tabela 7. Correspondência entre Práticas e Recomendações elaboradas ................................................. 28

Tabela 8. Recomendações Priorizadas ....................................................................................................... 29


1 Projecto de Dissertação FEUP-ARSN

1. Introdução

A elaboração do mapeamento teve como principal objectivo analisar os possíveis desvios das actuais

práticas do serviço de rastreio ao CCR da ARSN, tendo em conta as especificações do modelo CMMI-SVC.

Em paralelo e adicionalmente o modelo foi utilizado como guia, oferecendo, através do seu conjunto de

boas práticas, um leque de opções, procedimentos e relembrando qual o caminho típico no

desenvolvimento de um serviço.

O trabalho iniciou-se com o mapeamento das práticas relativas à área de processo do CMMI-SVC de

desenvolvimento do sistema de serviço – Service System Development (SSD) –, uma vez que é este o

estágio (do ciclo de vida) em que o serviço se encontra. Por “sistema de serviço” entende-se um sistema

de serviço é uma combinação integrada e interdependente de componentes do sistema que satisfazem

os requisitos dos stakeholders. Já uma “componente do sistema de serviço” é um processo, produto de

trabalho, pessoa, consumível, consumidor ou outro recurso necessário para o sistema de serviço

entregar valor. Os componentes do sistema de serviço podem incluir componentes pertencentes ao

consumidor ou a terceiros.

O Desenvolvimento do Sistema de Serviço (SSD – Service System Development) constitui uma área de

processos do CMMI-SVC. Esta é caracterizada como um conjunto de práticas relativas ao nome da área

em específico, as quais, quando implementadas em conjunto, satisfazem um conjunto de objectivos

considerados importantes para a sua melhoria ou optimização.

Como se pode ver pela Figura 1 o modelo define um conjunto de objectivos, específicos e genéricos,

pelo que, no presente projecto o objectivo é analisar os objectivos específicos da área de

desenvolvimento do sistema (SSD), transição (SST) e entrega do serviço (SD). Os objectivos específicos

possuem práticas específicas que se dividem ainda em subpráticas e exemplos de resultados.

Figura 1. Componentes Modelo CMMI

Process Area

Generic PracticesGeneric Practices

Generic GoalsGeneric Goals

Expected InformativeRequiredKEY:

Purpose

StatementIntroductory

Notes

Related

Process Areas

SubpracticesSubpractices

Specific GoalsSpecific Goals

Specific PracticesSpecific Practices

Typical Work

Products

Example Work

ProductsSubpracticesSubpractices Subpractices

Generic Practice

ElaborationsSubpracticesSubpractices



2. O procedimento

O procedimento passou por recolher do modelo CMMI-SVC a informação relativa a toda a área de

processo e componentes constituintes. Assim, construiu-se um template – Tabela 1 – esquematizando

cada prática específica, contendo: o nome da prática, o seu objectivo, as subpráticas, os exemplos de

resultados, o conjunto de informação recolhida junto da ARSN respeitante à prática, um campo para

classificação (rating), notas de observações e/ou recomendações e um campo final de eventuais

dúvidas.

Tabela 1. Template de esquematização das práticas específicas

SP X.x <Nome Prática Específica> Descrição da prática específica…

Subpráticas: 1. A 2. B

Exemplos de resultados da SP1.1 1. AA 2. BB

Informação Recolhida:

1. Info1 2. Info2

Fontes: Fonte1, Fonte2, Fonte3

Rating:

Notas: Nota1, Nota2, Nota3, etc

Dúvidas: 1. Dúvida1 2. Dúvida2

2.1. Classificação – Rating

A classificação atribuída teve por base a escala de fidelidade definida no modelo de avaliação utilizado

pelo SCAMPI C – método de avaliação para a framework CMMI [1]. A escala define, três níveis: “LOW”,

“MEDIUM”, “HIGH” e ainda a possibilidade do nível “OUT OF SCOPE” – nível atribuído a uma prática

quando está para além do âmbito do projecto.

Tabela 2. Escala SCAMPI C (Opcional)

Escala opcional de “Fidelidade” para o SCAMPI C

LOW A intenção da prática do modelo é considerada ausente, ou inadequadamente endereçada à abordagem; a obtenção do objectivo é considerada improvável pela ausência ou inadequação da prática.

MEDIUM A intenção da prática do modelo é considerada parcialmente endereçada à abordagem, e o suporte visível à obtenção do objectivo é limitado.

LOW/MEDIUM/HIGH



HIGH A intenção da prática do modelo é considerada adequada no conjunto de práticas (planeadas ou implantadas), de uma forma que defende o cumprimento da meta no contexto de determinado processo.

Fazendo uso da flexibilidade concedida pelo método SCAMPI C, foram atribuídas cores a cada nível e

adicionada a classificação “NOT YET” para qualificar as práticas que não foram ainda realizadas mas que

poderão, eventualmente, vir a ser. Os níveis “NOT YET” e “OUT OF SCOPE” são atribuídos nos casos em

que as subpráticas (SB) e exemplos de resultados (ER) são predominantemente classificados nessas

categorias (tipicamente com mais de 50%), não sendo então relevante o rating.

Figura 2. Escala de classificação das práticas tendo por base a escala de fidelidade do SCAMPI C.

Para o cálculo da classificação de cada prática específica foi utilizado o rácio entre o conjunto de

subpráticas e exemplos de resultados satisfeitos, o somatório do conjunto (SB+ER) de satisfeitos (S), não

satisfeitos (U), considerados não prioritários (NP), ainda não realizados (NY) e os fora do âmbito (OS).

Como podemos ver pela Figura 3, a cada classificação possível para as subpráticas ou exemplos de

resultados foi atribuído um peso, utilizado aquando do cálculo do rácio (Figura 4).

Figura 3. Peso de cada classificação de EWP ou SB.

Figura 4. Formula para o cálculo da classificação das práticas

Este exercício pretende fazer uma caracterização de alto nível das práticas utilizadas no serviço de

rastreio, identificando as oportunidades de melhoria nas quais a organização se poderá focar tendo em

conta a fidelidade ao modelo CMMI. Por fim, a apreciação dos objectivos assentou na média ponderada

das classificações de cada prática específica

- -

- -

0% 20%

21% 60%

61% 100%

Fidelity Scale - Scampi C

LOW

MEDIUM

HIGH

NOT YET

OUT OF SCOPE

ER&SB Classification Weight

Satisfied (S) 1 W1

Unsatisfied (U) 1 W2

Not a Priority (NP) 0,5 W3

Not Yet (NY) 0,33 W4

Out of Scope (OS) 0,25 W5

𝑅𝑎𝑡𝑖𝑛𝑔 =𝑆

(𝑆 ×𝑊1 + 𝑈 ×𝑊2 + 𝑁𝑃 ×𝑊3 + 𝑁𝑌 ×𝑊4 + 𝑂𝑆 ×𝑊5)



3. Desenvolvimento do Sistema de Serviço - Service System

Development (SSD)

O propósito do Desenvolvimento do Sistema de Serviço é analisar, desenhar, desenvolver, integrar,

verificar e validar o sistema de serviço, incluindo componentes, de modo a satisfazer acordos existentes

ou antecipar os mesmos no seu aparecimento.

The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and

validate service systems, including service system components, to satisfy existing or anticipated service

agreements [2].

O presente capítulo faz o mapeamento entre as práticas descritas do modelo CMMI-SVC e as seguidas

pela instituição ARS Norte, no que ao Desenvolvimento do Sistema de Serviço de Rastreios do Cancro do

Cólon e Recto diz respeito. Como apresentado anteriormente, o modelo define para cada área de

processo um conjunto de objectivos específicos e, para cada um destes objectivos, estabelece

subpráticas.

De seguida é apresentado o conjunto objectivos-práticas para esta área de processo:

SG 1 Develop and Analyze Stakeholder Requirements

SP 1.1 Develop Stakeholder Requirements

SP 1.2 Develop Service System Requirements

SP 1.3 Analyze and Validate Requirements

SG 2 Develop Service Systems

SP 2.1 Select Service System Solutions

SP 2.2 Develop the Design

SP 2.3 Ensure Interface Compatibility

SP 2.4 Implement the Service System Design

SP 2.5 Integrate Service System Components

SG 3 Verify and Validate Service Systems

SP 3.1 Prepare for Verification and Validation

SP 3.2 Perform Peer Reviews

SP 3.3 Verify Selected Service System Components

SP 3.4 Validate the Service System



3.1. SG 1 Develop and Analyze Stakeholder Requirements

Necessidades, expectativas, restrições e interfaces são recolhidas, analisadas e transformadas em

requisitos do sistema de rastreios validados.

SP 1.1 Develop Stakeholder Requirements

Coleccionar e transformar as necessidades, expectativas, restrições e interfaces dos stakeholders em requisitos dos mesmos.

Subpráticas: 3. Envolver os stakeholders relevantes utilizando métodos de “elicitação” de necessidades,

expectativas, restrições e interfaces externas; 4. Transformar necessidades, expectativas e restrições dos stakeholders em requisitos

priorizados; 5. Definir restrições para a verificação e validação.

Exemplos de resultados da SP1.1 3. Requisitos do Consumidor; 4. Requisitos do Utilizador final; 5. Restrição dos requisitos para a verificação e validação; 6. Restrições por parte do Staff.

Ex:

Listagens de Requisitos por Stakeholders;

Conflitos entre requisitos;

Definição de restrição para a fase de verificação e validação.

Informação Recolhida: Stakeholders identificados:

População Região Norte (Utentes);

ARSNorte;

Departamento de Estudos e Planeamento da ARSN;

Fabricantes dispositivos;

Laboratório de Patologia Clínica (LPC);

Laboratório Anatomia Patológica do CHP

Comissão Oncológica Regional;

Coordenação Local;

Unidades de Cuidados de Saúde Primários;

Serviço de Gastrenterologia; Requisitos identificados:

3. Realização de rastreio organizado, ao invés de oportunista; 4. O rastreio deve ser não invasivo; 5. Aceite pela população; 6. Simples de aplicar; 7. Com sensibilidade e especificidade altas; 8. Efectivo na redução da morbilidade e mortalidade; 9. Custos comportáveis; 10. Rastreio por testes PSOF – imunoquímicos; 11. Seguir uma metodologia de base populacional, organizada, centralizada,

com estreitos mecanismos de controlo e garantia de qualidade sujeito a auditorias;

12. Disponibilidade de diagnóstico complementar, tratamento e acompanhamento imediatos;

13. Acessibilidade Universal ao Utentes; 14. Informação dos Utentes para os Riscos Inerentes ao Rastreio; 15. Garantir o consentimento após informação sobre os benefícios e riscos

Fontes: Documento Fase Inicial RCCR, Entrevistas



desta actividade preventiva; 16. Garantir a comunicação dos resultados; 17. Possuir programa de garantia de qualidade; 18. Garantir à população a gratuitidade do Programa a implementar; 19. Manter os dispositivos a uma temperatura de 2 a 8ºC e de protege-los

da luz directa; 20. O Laboratório (LPC) tem 7 dias para a leitura dos testes; 21. Garantir 13.440 ou 50% dos utentes a rastrear anualmente; 22. Deve decorrer entre 2011 e 2013; 23. Deve ter a duração mínima de 24 meses; 24. Selecção e contratação do ou dos laboratórios de patologia clínica; 25. Garantir que o SiiMA Rastreios se encontra operacional; 26. Garantir integração do SiiMA Rastreios; 27. Garantir a adesão dos dirigentes e dos técnicos do laboratório,

assegurando formação específica; 28. Garantir ao LCP as amostras em correctas condições; 29. Garantir que o laboratório tenha condições para fazer a leitura dos

testes respeitando os intervalos de tempo de estabilidade do material biológico colhido;

30. Garantir a adesão quer dos dirigentes, quer dos profissionais de saúde; 31. Garantir formação dos profissionais envolvidos, quer no programa, quer

no sistema de informação; 32. Informar localmente (a população) do programa de rastreio em curso; 33. Elaborar o tríptico de acompanhamento do convite com informações

sobre o programa de rastreio, teste preconizado e actuações subsequentes de forma a permitir a obtenção do consentimento informado, por parte dos utentes;

34. Garantir que o tubo de colheita do material biológico seja acompanhado por instruções em língua portuguesa;

35. Garantir que as unidades de cuidados de saúde primários tenham condições para manter os tubos, com o material biológico já colhido, a uma temperatura de 2 a 8ºC protegendo-os da luz directa;

36. Garantir que as unidades de cuidados de saúde primários tenham condições para enviar/transportar os tubos, com o material biológico já colhido, para os laboratórios de patologia clínica respeitando as condições de estabilidade do produto (tempo de transporte para a leitura e temperatura do material).

Rating:

Notas: Apesar de ser identificado um conjunto alargado de requisitos, não foram consultados e envolvidos todos os stakeholders do serviço de rastreios. Esta situação poderá levar a que não seja possível uma prévia preparação das características necessários para cada stakeholder, e apenas sejam identificados alguns requisitos importantes numa fase avançada do ciclo de vida do serviço. Não existe a identificação entre requisitos e os respectivos stakeholders pelo que, uma grande parte dos requisitos tem origem em programas de rastreios anteriores, podendo não estar correctamente adequados. Por outro lado, não existe a identificação de possíveis requisitos derivados. A anterior listagem dos requisitos, foi elaborada tendo em conta a documentação e entrevistas realizadas, pelo que, a sua numeração não corresponde à sua priorização, característica em falta e recomendada pelo modelo. Para ajudar a identificação e manipulação dos requisitos foi construído um template.

Dúvidas: 3. Como foram identificados os requisitos para o serviço de rastreios, quais as suas fontes?

a. Conhecimento adquirido? b. Recomendações europeias, plano nacional saúde?

LOW

http://paginas.fe.up.pt/~meg09027/lib/exe/fetch.php?media=wiki:gestao_requisitos_servico_gestao_rastreios_ars_norte.xls



c. Relatórios de saúde – oncologia? d. Foram consultados os vários stakeholders?

R: Conjunto de Guidelines Internacionais, recomendações PNS e conhecimento entretanto adquirido. 4. Houve a transformação das necessidades, expectativas em requisitos do serviço de

rastreios? R: Não existiu um tratamento cuidado dos requisitos.

SP 1.2 Develop Service System Requirements

Refinar e elaborar os requisitos dos stakeholders para o desenvolvimento dos requisitos do sistema de rastreios.

Subpráticas: 1. Desenvolvimento dos requisitos e expressá-los nos termos necessários para o serviço e o

desenho do sistema de serviço; 2. Requisitos derivados que resultam da solução seleccionada e das decisões de desenho; 3. Estabelecimento e manutenção das relações entre os requisitos para consideração durante

a gestão da mudança e alocação de requisitos; 4. Priorização de requisitos derivados; 5. Alocação de requisitos a entidades lógicas, componentes dos sistemas de serviço, e outras

entidades; 6. Identificação de interfaces, quer internas quer externas ao sistema de serviço; 7. Desenvolvimento de requisitos para as interfaces identificadas;

Exemplos de resultados da SP1.2 1. Requisitos derivados com relações e prioridades; 2. Requisitos do sistema; 3. Requisitos do sistema de serviço (rastreios); 4. Alocação de requisitos; 5. Requisitos de arquitectura, com especificação ou restrição das relações entre os

componentes do sistema de serviço. 6. Requisitos de interfaces; 7. Requisitos em termos dos conhecimentos por parte dos colaboradores;

Informação Recolhida: Requisitos do Serviço de Rastreios:

1. Realização de rastreio organizado, ao invés de oportunista 2. O rastreio deve ser não invasivo 3. Aceite pela população 4. Simples de aplicar 5. Com sensibilidade e especificidade altas 6. Efectivo na redução da morbilidade e mortalidade 7. Custos comportáveis 8. Rastreio por testes PSOF – imunoquímicos 9. Seguir uma metodologia de base populacional, organizada, centralizada,

com estreitos mecanismos de controlo e garantia de qualidade sujeito a auditorias.

10. Disponibilidade de diagnóstico complementar, tratamento e acompanhamento imediatos

11. Acessibilidade Universal ao Utentes 12. Informação dos Utentes para os Riscos Inerentes ao Rastreio 13. Garantir o consentimento após informação sobre os benefícios e riscos

desta actividade preventiva 14. Garantir a comunicação dos resultados

Fonte: Documento Fase Inicial RCCR.



15. Possuir programa de garantia de qualidade 16. Garantir à população a gratuitidade do Programa a implementar 17. Garantir 13.440 ou 50% dos utentes a rastrear anualmente 18. Deve decorrer entre 2011 e 2013 19. Deve ter a duração mínima de 24 meses

Rating:

Notas: Existe um conjunto vasto de requisitos do serviço e do sistema de serviço que o suporta. No entanto, não são identificados e/ou desenvolvidos possíveis requisitos derivados bem como as suas eventuais relações. São identificadas algumas restrições no desenho do serviço e na interface com o aplicativo, porém não existe uma listagem explícita das interfaces e descrição correspondente. Não são listados os requisitos das interfaces entre os componentes do sistema de serviço ex: Aplicativo Informático, Enfermeiros-Utente, LPC-Utente, etc O serviço de rastreio sofreu algumas mutações ao longo do tempo – com diferentes locais e timmings de realização – pelo que os requisitos do sistema de serviço foram também mudando. Apesar desta situação, o processo de alteração dos requisitos não respeitou qualquer mecanismo de redefinição iterativa – recomendada pelo modelo.

Dúvidas: 1. Requisitos entre de interfaces; R: Desconhecimento da realidade do terreno. 2. Requisitos em termos de conhecimentos dos colaboradores; R: Não estão identificados.

SP 1.3 Analyze and Validate Requirements

Analisar e validar os requisitos, e definir as funcionalidades necessárias do sistema de rastreios.

Subpráticas: 1. Desenvolver cenários e conceitos operacionais que incluam operações, instalação,

desenvolvimento, manutenção, suporte e apresentação apropriadas; 2. Desenvolver conceitos operacionais detalhados que definam a interacção do sistema de

serviço, utilizadores finais, e o ambiente que satisfaça necessidades operacionais, de manutenção, suporte e apresentação;

3. Estabelecer e manter a definição das funcionalidades requeridas e atributos de qualidade; 4. Analisar os requisitos para assegurar que são necessários e suficientes e balancear as

necessidades e restrições dos stakeholders; 5. Validar os requisitos para assegurar que o sistema de serviço resultante irá funcionar como

pretendido em ambiente “real” e com os utilizadores finais.

Exemplos de resultados da SP1.3 1. Conceitos e cenários operacionais, use cases, diagramas de actividades e “user stories”; 2. Conceitos do sistema de serviço e seus componentes, de formação, manutenção, suporte e

disposição; 3. Definição de requisitos funcionais e atributos de qualidade; 4. Requisitos de qualidade em termos de arquitectura; 5. Novos Requisitos; 6. Relatórios de eventuais defeitos nos requisitos e propostas de resolução; 7. Avaliação dos riscos relativos aos requisitos; 8. Salvaguarda dos resultados e métodos de análise.

Informação Recolhida: N/A

Fonte: Entrevistas

MEDIUM



Rating:

Notas: Tomando em consideração o modelo de referência não são conhecidos cenários operacionais e funcionais tendo em conta os requisitos identificados. São definidas algumas das funcionalidades requeridas pelo sistema de serviço. No entanto, ainda não existe a sua validação junto dos vários stakeholders. Este facto poderá levar à reformulação ou mesmo adição de novos requisitos. Tendo em conta as especificidades do serviço, a sua validação ocorrerá quase sempre em ambiente real, pelo que será necessário acautelar esta situação – a ser tratada numa prática posterior. Alguns dos requisitos, apesar de identificados, não mereceram ainda análise por parte de todos os intervenientes não sendo possível classificá-los entre necessários e suficientes e balancear as necessidades e restrições dos stakeholders; Alguns dos pontos sugeridos pelo modelo poderão não se aplicar directamente ao serviço de RCCR – particularidade do serviço.

Dúvidas: 1. Inexistência de evidências sobre análises aos requisitos. Foi realizada de alguma forma esta

análise? a. Informalmente – reuniões b. Existe documentação?

2. Realizada a validação dos requisitos dos vários stakeholders? R: Não existiu até ao momento análise pormenorizada e validação dos requisitos. A serem validados reunião com ACES.

3.1.1 Classificação do Objectivo

A classificação do objectivo “Desenvolver e Analisar os Requisitos dos Stakeholders e do Sistema” teve

em conta as classificações das várias práticas, sendo na realidade a sua média. Desta forma, o objectivo

obteve a classificação de “MEDIUM”.

Ilustração 1. Classificação Objectivo 1

3.2. SG 2 Develop Service Systems

Componentes do sistema de serviço são seleccionadas, desenhadas, implementadas e integradas.

Foco nas actividades:

Avaliação e selecção de soluções, que potencialmente satisfazem um conjunto apropriado de

requisitos;

Desenvolvimento de desenhos detalhados para as soluções seleccionadas;

Implementação, quando necessário, dos desenhos dos componentes do sistema de serviço;

Integração do sistema de serviço para que as funções e atributos de qualidade possam ser

verificadas e validadas.

SP 2.1 Select Service System Solutions

Seleccionar soluções para o serviço de entre diferentes opções.

Subpráticas: 1. Estabelecer e definir critérios para a selecção dos diferentes componentes; 2. Desenvolver soluções alternativas;

MEDIUM

MEDIUM



3. Seleccionar as soluções para o sistema de serviço que melhor satisfazem os critérios estabelecidos.

Exemplos de resultados da SP2.1 1. Critérios de soluções alternativas; 2. Critérios de triagem de soluções; 3. Decisões de selecção de componentes; 4. Relações entre os requisitos e os componentes do serviço são documentadas; 5. Documentação das soluções, avaliações e fundamentação lógica.

Informação Recolhida: 1. Existem critérios de selecção definidos para os vários componentes do

serviço? R:

a. Critérios segundo as normas internacionais – soluções com certificação

b. Este é um concurso de baixo nível c. KITS:

i. Preços ii. Experiência

iii. Todas as entidades existentes iv. Compatibilidade v. Necessidade de Mecanismos de leitura

2. Existem soluções alternativas, estudos de alternativas? R:

a. Dispositivo de recolha amostra; - obtenção de uma proposta por todos os fornecedores

b. SiiMA Rastreios: i. Sistema comprado pelo alto comissariado para todo o

país; ii. Plataforma utilizada para os anteriores rastreios;

iii. Profissionais habituados; iv. Info Adquirida por ambas as partes;

c. Centro Hospitalar do Porto (CHP): i. Estudadas outras hipóteses – Vila Real, Braga;

ii. Interesse demonstrado pelo CHP; iii. Proximidade entre ARSN, ACES, CHP – condições

privilegiadas para a monitorização e controlo; iv. Unidade de “Gastreo” foi recentemente reforçada e

melhorada – níveis de qualidade superiores; v. Interesse de rentabilização do serviço por parte do

CHP; d. Laboratório Patologia Clínica (LPC):

i. Unidade de LCP do CHP – utiliza o mesmo SI; ii. Está dentro do mesmo hospital – “oportunidade”;

iii. Ainda não é certo que o nº de testes a realizar seja exequível;

iv. Está em falta o estabelecimento de um protocolo com o CHP para este serviço;

v. O LCP não se encontra adaptado para a realização de serviços externos ao CHP;

e. ACES do Porto Ocidental; i. Faz parte dos ACES do CHP;

ii. Proximidade do ACES ocidental para com o CHP iii. Bons transportes entre ACES e CHP – cuidado com a

perspectiva utentes; f. Escolha de teste imunoquímicos:

i. Preço; ii. Capacidade Resposta

Fonte: Documento Fase Inicial RCCR; Entrevistas; Site ARSN.



iii. Questões Culturais 3. As soluções cumprem com os critérios definidos? R: Inexistência de critérios plenamente definidos.

Componentes do sistema de serviço:

SI Siima Rastreios

Base de Dados (BD) SINOS

Kit Rastreios ACES:

Instalações ACES;

Recursos Informáticos;

SAM – Módulo Administrativo

Enfermeiro(a)

Medico(a)

Administrativo(a)

Aprovisionamento Kits

Transporte ARSN:

Colaboradores

Coordenação – componente de decisão e técnica Laboratório Patologia Clínica (LPC):

Instalações do laboratório

Técnicos laboratoriais

Aparelho/Mecanismos de realização testes PSOF Serviço Anatomia Patológica:

Instalações

Colaboradores

Sistemas de Informação do Serviço Serviço Gastrenterologia:

Instalações

Colaboradores

SI SONHO - Administrativo

MobilWave - Videocolonoscopia

SAM – Módulo Clínico Esquema do serviço em termos de componentes do serviço:

Esquema disponível no Anexo A.



Rating:

Notas: Não estão definidos e/ou documentados os critérios para a selecção dos diferentes componentes. No entanto, como resultado das entrevistas foi possível identificar um conjunto de critérios provenientes de conhecimentos adquiridos e comuns ao desenvolvimento de serviços na área da saúde. Ex: Certificações Internacionais, Recomendações OMS, etc Muitas das soluções encontradas para o sistema de serviço são únicas, não existindo alternativas documentadas. Este facto pode-se dever à especificidade do serviço em questão e ao conjunto de entidades envolvidas, em que é dada prioridade aos serviços do Centro Hospitalar do Porto – Serviço Gastrenterologia, Anatomia Patológica, Laboratório Patologia Clínica – dado factores de proximidade e disponibilidade. A abordagem à implementação do serviço é ainda fortemente influenciada pelo anterior serviço de rastreio ao cancro do cólon e útero. Esta abordagem poderá não ser eficaz, dada as novas especificidades do rastreio em questão. “A potentially ineffective approach to implementing this practice is to generate solutions that are based on only the way services have been delivered in the past” [3]. Ainda não existe protocolo estabelecido com o laboratório de patologia clínica (LPC) ou com o próprio CHP. O LCP não está familiarizado com a realização de serviços externos ao hospital, necessários neste rastreio. Falta a definição de procedimento de facturação, preços de testes PSOF e exames de videocolonoscopia – a ser abrangidos pelo protocolo a estabelecer com o CHP. De todos os componentes do sistema de serviço, o CHP é o que “maiores dúvidas coloca”. Apesar dos contactos estabelecidos entre a ARSN e o CHP, ainda não estão definidos os moldes de colaboração no serviço de rastreios do CCR.

Dúvidas: N/A


Desenvolver conceitos para os componentes e o sistema de serviço.

“A documentação do desenho do serviço fornece uma referência para a compreensão dos diversos stakeholders e suporta futuras mudanças ao desenho quer na fase de desenvolvimento como nas subsequentes fases do ciclo de vida dos serviços.”

Subpráticas: 1. Desenvolver um conceito para o sistema de serviço; 2. Assegurar que o conceito endereça aos requisitos funcionais e de qualidade alocados; 3. Documentar o conceito; 4. Desenhar as interfaces para os componentes do sistema de serviço utilizando critérios

estabelecidos; 5. Avaliar quais as componentes do sistema de serviço que devem ser desenvolvidas,

compradas ou reutilizadas, tendo por base os critérios estabelecidos.

Exemplos de resultados da SP2.2 1. Arquitectura do sistema de serviço; 2. Desenho dos componentes e consumíveis do sistema de serviço; 3. Descrição do nível de formação necessário pelos colaboradores e necessidades de alocação

de novos colaboradores; 4. Especificações do desenho das interfaces; 5. Critérios de desenho e reutilização dos componentes do sistema de serviço; 6. Resultados de eventuais análises da compra ou construção de soluções.

MEDIUM



Ex: 1. Descrição dos papéis, responsabilidades, autoridades, prestação de contas e capacidades

das pessoas necessárias para a entrega do serviço; 2. Casos de Uso funcionais descrevendo os papéis e actividades dos participantes no serviço; 3. Desenho de templates para manuais, formulários, material de treino e guias para os

utilizadores finais, operadores e administrativos;

Informação Recolhida: Arquitectura do Sistema de Serviço: Fluxograma

Metodologia do Rastreio definida;

Identificação das funções de cada uma das entidades envolvidas no programa de rastreios.

Identificação das principais componentes dos rastreios e suas funções; o Componente populacional; o Execução do teste; o Componente clínica; o Coordenação;

Descrição das funções de cada entidade. Questões no âmbito da entrevista:

1. O fluxograma foi construído tendo em conta a opinião/requisitos dos diferentes stakeholders? R: Não, será realizada uma reunião de apresentação do programa. Organização Centralizada e “Vertical”.

2. O conceito de serviço cumpre com os requisitos? R: Não existe confirmação.

3. Estão documentados os diferentes papéis e responsabilidades no

Fonte: Documento Fase Inicial RCCR; Entrevistas: Site ARSN



serviço de rastreio? R: Será algo a realizar. 4. Estão identificadas as actividades/procedimentos a realizar em cada

etapa do fluxograma? R: Será algo a realizar. 5. A responsabilidade de realização do manual de procedimentos é da

coordenação local? R: Não, é da responsabilidade da ARSN.

Manual de Procedimentos “O actual manual de procedimentos constitui um instrumento de trabalho, da responsabilidade dos serviços de coordenação regional do programa de rastreio, e contempla os procedimentos específicos e relativos às unidades de cuidados de saúde primários no âmbito deste programa.” em RCCU.

6. Existem esquemas funcionais para cada actividade/procedimento no fluxograma?

a. Intervenientes; b. Responsáveis; c. Inputs d. Outputs

R: Não, mas será algo a realizar. 7. Emissão de Cartas-Convites Personalizadas – Existe template

(Semelhança RCCU)? R: Não, mas será algo a realizar. 8. Quem interage com o programa informático (SiiMA Rastreios)?

i. Segundo informação (CSP, LPC, CHP). 9. O programa SiiMA Rastreios está funcional? R: Neste momento os procedimentos estão parados – Falta a validação do fluxograma por parte dos vários intervenientes – mas a o SI já foi visto a funcionar aquando da reunião com a empresa desenvolvedora.

Rating:

Notas: Em termos de arquitectura, o serviço contava com um fluxograma que permitia obter uma visão global do sistema de serviço, este fluxograma sofreu já alterações com vista à sua melhoria em termos de divisão por processos, actividades e tarefas (Anexo C). As alterações entretanto realizadas permitiram ainda debruçar sobre as várias etapas do serviço, alternativas, restrições e necessidades e endereçar os requisitos funcionais e de qualidade. A metodologia do serviço juntamente com as funções dos diversos intervenientes está já documentada. No entanto, o conjunto de procedimentos e/ou actividades de cada processo ainda não está descrito. Um template para essa descrição é apresentado na análise de identificação do conjunto de processos – Anexo B – dando origem a um documento à parte [4]. Com o seu preenchimento o desenho do sistema de serviço estará plenamente documentado – seguindo as recomendações do modelo de referência. A identificação e especificação dos componentes do sistema de serviço permitiu identificar o conjunto de interfaces. Todavia, existe trabalho a realizar na definição dos critérios destas mesmas interfaces. A falta destes critérios (ex: segurança, durabilidade, missão, etc), como referido pelo modelo, poderá trazer dificuldades em momentos futuros do serviço. Poderão existir componentes a ser adquiridos acerca dos quais, neste momento, não existe a certeza sobre a sua necessidade, ex: dispositivos de conservação dos kits nos ACES.

Dúvidas: N/A

SP 2.3 Ensure Interface Compatibility

Garantia de compatibilidade entre interfaces. Gestão de definições, desenho e mudanças das interfaces internas e externas do sistema de serviço.

HIGH



Uma interface pode ser caracterizada como interacções entre diferentes componentes do sistema (pessoas, SI, local de análise, etc).

Subpráticas: 1. Revisão da cobertura e abrangência das descrições das interfaces; 2. Gestão da definição, desenho e mudança das componentes do serviço nas interfaces

internas e externa.

Exemplos de resultados da SP2.3 1. Categorização das diferentes interfaces (Externas e Internas):

o Pessoa-a-pessoa; o Pessoa-componente; o Componente-componente; o Interfaces compostas;

2. Mapeamento das relações entre as diferentes interfaces; 3. Lista das interfaces acordadas para cada par de componentes do sistema de serviço; 4. Relatórios das reuniões da equipa de trabalho de interfaces; 5. Acção a tomar/alterações para a actualização das interfaces; 6. Actualização da descrição das interfaces ou do acordo estabelecido.

Ex: 1. Scripts de interacção com o consumidor; 2. Criação de aplicativos (software) de interfaces.

Informação Recolhida: Existem vários SI que interagem com o serviço de rastreios (SAM, Mobilwave, SiiMA), no entanto, a sua comunicação não está plenamente assegurada. A comunicação entre os vários componentes identificados ainda não é uma realidade. Será necessário formar colaboradores, adaptar procedimentos e criar rotinas até então inexistentes. Aplicativo informático de apoio ao sistema de informação do rastreio:

1. Garantir que o aplicativo informático, adquirido pela Coordenação Nacional da Doenças Oncológicas do Alto Comissariado da Saúde para o programa de rastreio organizado do Cancro do cólon e do recto, esteja em condições de ser utilizado nesta fase inicial do programa na região Norte;

2. Garantir que o aplicativo esteja acessível/integrado nas unidades de saúde seleccionadas para a fase inicial deste rastreio (CSP, LPC e CHP).

Interfaces Serviço Rastreios:

1. Administrativos e Utentes – Primeiro Atendimento 2. Enfermeiros e Utentes no processo de atendimento da população 3. Enfermeiro - SiiMA Rastreios 4. Médico – Utente 5. Médico – SiiMA Rastreios 6. LCP e Utentes no envio de resultados 7. LCP – SiiMA Rastreios 8. SiiMA Rastreios e dispositivo de realização dos testes PSOF 9. SiiMA Rastreios e o Sistema do CHP (SONHO) 10. Serviço Gastrenterologia e Utente 11. Serviço Gastrenterologia e SiiMA Rastreios

Fonte: Documento Fase Inicial RCCR, Entrevistas.

Rating:

Notas: Através desta análise foram identificadas as várias interfaces entre os componentes do serviço de rastreios. As interacções entre os componentes estarão descritas pelo conjunto de documentação dos

LOW



processos – trabalho em curso. Não existe a categorização, uma descrição detalhada, um mapeamento e uma equipa de trabalho específica para a questão das interfaces dos componentes do sistema de serviço, como referido no modelo. É apenas identificado, na documentação do projecto inicial do rastreio, a necessidade de trabalhar/desenvolver as interfaces em termos de aplicativos de software, sendo que seria necessário um nível de descrição superior, quer desta interface crucial, como de todas as outras entretanto identificadas.

Dúvidas: 1. Estão identificadas as diferentes interfaces do sistema (segundo caracterização de

interfaces do CMMI)? R: Não. 2. Os requisitos das interfaces estão identificados? R: Não.

SP 2.4 Implement the Service System Design

Implementação (criação) dos componentes desenhados para o sistema de serviço. “Implementação” não significa colocar no terreno – temática a ser tratada na área de processo Service System Transition – mas sim o conjunto procedimentos relativos à criação/desenvolvimento dos componentes desenhados.

Subpráticas: 1. Utilização de métodos eficientes para a implementação das componentes do sistema do

rastreio; 2. Aderir a standards e critérios aplicáveis; 3. Conduzir peer reviews para componentes seleccionados do rastreio; 4. Realizar testes autónomos a componentes do rastreio; 5. Revisão do sistema de serviço como necessário.

Exemplos de resultados da SP2.4 1. Implementação das componentes do sistema do rastreio; 2. Desenvolvimento de matérias para formação; 3. Manuais de utilizador, operadores e manutenção; 4. Descrição de procedimentos; 5. Registo de novas contratações e eventuais transferências de colaboradores; 6. Registo de comunicações sobre mudanças organizacionais.

Exemplos de actividades:

1. Compatibilidade das interfaces é confirmada; 2. Entrega incremental das funcionalidades dos componentes; 3. Software é construído/desenvolvido; 4. Materiais de treino são desenvolvidos; 5. Partes mecânicas e eléctricas são fabricadas; 6. Procedimentos que implementas os processos desenhados são escritos; 7. Instalações são construídas; 8. São estabelecidos os acordos para a prestação de serviço com fornecedores; 9. São contratados ou transferidos colaboradores (staff); 10. As estruturas organizacionais e de equipas são estabelecidas; 11. Consumíveis personalizados são construídos (ex: dispositivos específicos)

Informação Recolhida: Descrição dos procedimentos com utilização do template para a descrição dos processos. As eventuais formações serão adaptadas consoante os colaboradores-alvo. Não está prevista a contratação de novos colaboradores, mas sim a formação dos já

Fonte: Documento Fase Inicial RCCR, Entrevistas.



existentes, em especial o conjunto de administrativos-enfermeiros.

Rating:

Notas: Ainda não foi assegurada a disponibilidade de todos os componentes do sistema de serviço, em particular os componentes externos à ARSN, ou seja, os relativos ao Centro Hospitalar do Porto (CHP). As descrições dos procedimentos serão realizadas aquando a descrição dos processos. Os componentes que fazem parte do CHP podem não estar familiarizados com o SiiMA Rastreios ou com a prestação de serviços externos – o modo de procedimento deve ser melhor esclarecido. A obtenção do apoio por parte dos componentes do serviço que fazem parte do CHP será importante através do:

1. Estabelecimento Protocolo 2. Assegurar a prestação dos serviços externos 3. Assegurar a correcta comunicação de resultados – troca de informação entre o SI do CHP e o -

SiiMA Rastreios (da responsabilidade da FirstSolutions); 4. Envolvimento dos colaboradores do CHP

Certas práticas estão ainda pendentes da validação da solução do desenho do serviço junto dos restantes stakeholders – desenvolvimento de materiais de formação.

Dúvidas: 1. Formação para os colaboradores – necessidade especial? R: Será dada formação a

enfermeiros e administrativos

SP 2.5 Integrate Service System Components

Reunir e integrar os componentes do sistema de serviço implementado através de um sistema de serviço verificável.

Subpráticas: 1. Desenvolver uma estratégia para a integração do sistema de serviço. 2. Garantir o ambiente para a pronto integração; 3. Confirmar que cada componente necessário do serviço está correctamente identificada e o

seu comportamento está em concordância com as descrições. 4. Avaliar o sistema de serviço implantado em termos de compatibilidade e comportamento

(funcionalidade e atributos de qualidade).

Exemplos de resultados da SP2.5 1. Estratégia de integração do sistema de serviço; 2. Integração documentada e verificada; 3. Procedimentos e critérios de integração; 4. Relatórios de Excepções; 5. Componentes no serviço montados; 6. Relatórios de avaliação de interfaces; 7. Relatórios sumários da integração do sistema de serviço; 8. Plano das sequências de integração – como e onde?

Informação Recolhida:

O comportamento de alguns componentes do serviço de rastreio ainda não é totalmente conhecido - Existem algumas dúvidas sobre o fornecimento de resultados por parte do LCP ou CHP.

Não existe uma estratégia delineada para a integração de todos os componentes do sistema de serviço.


MEDIUM



Rating:

Notas: O Serviço de RCCR ainda não abordou este conjunto de subpráticas – carece de validação da solução do desenho do serviço junto dos restantes stakeholders. Ainda não existe data para a realização da prática em específico.

Dúvidas: 1. Existe plano de integração com lista de sequências e procedimentos? 2. Verificação se cada componente cumpre os requisitos de interface. 3. Realização do conjunto de subpráticas.


A classificação do objectivo “Desenvolver o Sistema de Serviço” teve em conta as classificações das

várias práticas, sendo na realidade a sua média. Desta forma, o objectivo obteve a classificação de

“MEDIUM”.

Ilustração 2. Classificação Objectivo 2

3.3. SG 3 Verify and Validate Service Systems

Componentes seleccionadas do sistema de serviço são verificados e validados para garantirem a entrega

correcta do serviço (Rastreio).

O que deve ser verificado e validado?

Pessoas;

Processos;

Equipamentos;

Software;

Consumíveis;

Verificação: Garante se “you built it right”;

Validação: Garante se “you build the right thing”;

Métodos de Verificação Métodos de Validação Inspecções;

Revisões por pares;

Auditorias;

Walkthroughs;

Análises;

Simulações;

Testes;

Demonstrações;

Discussões com utilizadores;

Demonstrações de protótipos;

Apresentações funcionais;

Materiais de formação;

Testes dos serviços e dos componentes do sistema de serviço pelos utilizadores finais e outros stakeholders;

SP 3.1 Prepare for Verification and Validation

Estabelecer e manter uma abordagem e um ambiente para a verificação e validação.

NOT YET

MEDIUM



Subpráticas: 1. Seleccionar as componentes do serviço a ser verificadas e validadas e quais os métodos a

ser utilizados em cada; 2. Estabelecer e manter o ambiente necessário para suportar a verificação e validação; 3. Estabelecer e manter procedimentos e critérios para os componentes do serviço.

Exemplos de resultados da SP3.1 1. Listagens dos componentes do sistema de serviço a validar e verificar; 2. Identificação de métodos para verificação e validação de cada componente; 3. Preparação do ambiente de verificação e validação; 4. Preparação dos procedimentos de verificação e validação; 5. Preparação dos critérios de verificação e validação.

Informação Recolhida: Conjunto de informação da Fase Inicial do Programa de Rastreios CCR.

Fonte: Documento Fase Inicial RCCR, Entrevistas

Rating:

Notas: Ainda não existe data para a realização da prática em específico. Carece de validação junto dos ACES e CHP quando à organização do programa de rastreios.

Dúvidas: 1. As opções para os testes do sistema de rastreios enquadram-se nos requisitos?

a. CHO, UCS, LPC 2. É necessário verificar todos os componentes?

a. Quais serão os verificados?


Realização de revisões por pares em componentes do sistema de serviço seleccionados. O que é a revisão por pares? A revisão de pares é uma tarefa executada (interna ou externa) de forma a garantir que toda a documentação ou outros recursos que são entregues ao cliente é revista por mais do que uma pessoa dentro da organização. Desta forma garante-se a qualidade das entregas ao cliente assim com se detectam internamente erros que podem ser corrigidos para que não aconteçam no futuro, melhorando e capacitando assim a equipa regularmente.

Subpráticas: 1. Determinar que tipo de revisões “por partes” serão realizadas; 2. Estabelecer e manter procedimentos e critérios para as revisões por pares; 3. Definir os requisitos da revisão; 4. Estabelecer e manter checklists; 5. Desenvolver e planear as revisões por pares a realizar; 6. Preparação para as revisões por pares; 7. Garantir que os componentes do sistema de serviço satisfazem os critérios definidos; 8. Atribuição de papéis para a revisão; 9. Conduzir revisão por pares; 10. Conduzir revisões adicionais se for necessário; 11. Garantir que os critérios de saída da revisão são satisfeitos; 12. Registo e salvaguarda dos dados relativos à preparação, realização e resultados obtidos; 13. Analisar os dados da revisão.

NOT YET



Exemplos de resultados do SP3.2 1. Agenda da revisão por pares – planeamento; 2. Revisão por pares – Checklist; 3. Critérios de entrada e saída das componentes do sistema de serviço e trabalhos realizados; 4. Critérios relativos à necessidade de nova revisão por pares; 5. Material de formação; 6. Componentes do sistema de serviço seleccionados; 7. Resultados da revisão, incluindo problemas e acções a tomar; 8. Dados da revisão por pares.

Informação Recolhida: A ARSN tem conhecimento do conceito de revisão por pares. Todo o trabalho será revisto pela Comissão Oncológica Regional (COR). Esta possui um conjunto de peritos que farão a verificação/revisão. Posteriormente haverá ainda a revisão por parte do Conselho Directivo da ARSN. A revisão pela COR será o que mais se assemelha a uma revisão por pares. Não existem critérios ou procedimentos estabelecidos pela ARSN.


Rating:

Notas: A realização desta prática não está totalmente no âmbito do projecto, pelo que todas as revisões estarão a cargo do COR e do Conselho Directivo da ARSN.

Dúvidas: N/A

SP 3.3 Verify Selected Service System Components

Verificar os componentes do sistema de serviço face aos seus requisitos especificados.

Subpráticas: 1. Realização de verificações de componentes do sistema de rastreios face aos requisitos

especificados; 2. Salvaguarda dos resultados das actividades de verificação; 3. Identificação dos itens de acções resultantes da verificação; 4. Documentar a verificação “as-run” e o conjunto de desvios; 5. Análise e salvaguarda dos resultados de todas as actividades de verificação.

Exemplos de resultados da SP3.3 1. Resultados das verificações; 2. Relatórios das verificações; 3. Relatório de análise (estatísticas de performance, análise causal e comparação entre o

comportamento, o serviço real e os modelos e tendências); 4. Relatórios de problemas identificados; 5. Pedidos de mudanças aos métodos de verificação, critérios e ambiente.



Rating:

Notas: Alguns componentes transitam de outros rastreios e/ou da ARS Centro e do seu programa de rastreios. Já foi possível à ARSN verificar o SiiMA Rastreios a funcionar para o RCCR junto da empresa responsável.

NOT YET

NOT YET



Ainda não existe data para a realização da prática em específico.

Dúvidas: 1. Haverá a verificação dos componentes, com os requisitos previamente estabelecidos? 2. Haverá verificações antes da colocação em curso da fase inicial? 3. Como serão realizadas?

SP 3.4 Validate the Service System

Validar o serviço de rastreios de forma a garantir que este é utilizável no ambiente em que foi projectado e que cumpre com as expectativas de todos os stakeholders.

Subpráticas: 1. Realização de validações de funcionalidades e atributos de qualidade nos componentes do

sistema de rastreios; 2. Análise dos resultados das actividades de verificação.

Exemplos de resultados do SP3.4 1. Relatórios e resultados da validação; 2. Matriz de validação; 3. Relatórios de deficiências e outros problemas; 4. Solicitação de mudança para validação de métodos, critérios e meio ambiente; 5. Validação da aceitação por parte dos utilizadores da entrega do serviço; 6. Relatórios de Focus Groups.



Rating:

Notas: A validação do sistema de serviço será realizada em ambiente real, com a possibilidade de existência de um faseamento específico, ainda por decidir. Ainda não existe data para a realização da prática em específico.

Dúvidas: 1. Supostamente só acontecerá com o plano inicial de rastreios em funcionamento?

R: Sim, poderão apenas existir validações pontuais no que aos sistemas de informação diz respeito.


A classificação do objectivo “Verificar e Validar o Sistema de Serviço” teve em conta as classificações das

várias práticas, sendo na realidade a sua média. Desta forma, o objectivo obteve a classificação de “NOT

YET”.

Ilustração 3. Classificação do Objectivo 3

3.4. Resultado

Como resultado do mapeamento das práticas, foi elaborado um documento anexo utilizando o template

anteriormente apresentado e contendo uma tabela por prática. No total foram criadas e preenchidas 14

tabelas, cada uma reunindo a informação associada à prática específica.

NOT YET

NOT YET



A Tabela 3 expõe detalhadamente as classificações da área de processo de desenvolvimento do sistema

de serviço. As colunas “SB” e “ER” são meramente informativas, apresentando o número total de

subpráticas e exemplos de resultados para cada prática específica do modelo. As classificações para

subpráticas e exemplos de resultados obtidas pela organização são apresentadas nas colunas seguintes,

separados pelas categorias definidas (Figura 3). A existência de valores não inteiros nos resultados

obtidos justifica-se pelo facto de existirem casos em que se achou mais adequado considerar parte da

subprática ou exemplo de resultado numa categoria e outra parte noutra. O resultado do cálculo da

classificação pela fórmula anterior (Figura 4) é apresentado na coluna “Rating”.

Constata-se ainda a ausência de práticas ou exemplos de resultados consideradas fora do âmbito (“OUT

OF SCOPE”), atributo que poderá resultar do carácter genérico e abrangente do modelo CMMI-SVC. É

ainda visível a predominância do nível “MEDIUM” quanto à fidelidade para com o modelo, entre as

práticas específicas já cobertas pelo projecto, e a existência de um maior número de práticas específicas

com nível “LOW” face às com nível “HIGH”.

Tabela 3. Classificação detalhada de toda a área de processo [12]

Os campos de “rating” do template foram preenchidos tendo em conta a tabela anterior, sendo que a

Tabela 4 apresenta o quadro resumo da área de processo.

Rating ER SB Fidelity

S U NP NY OS S U NP NY OS

15% 4 3 LOW 1 2 1 0 0 0 3 0 0 0

34% 7 7 MEDIUM 2,5 1 3,5 0 0 2 5 1 0 0

22% 8 5 MEDIUM 1,5 3,5 3 0 0 1 4 1 0 0

21% 5 3 MEDIUM 1 2,5 1,5 0 0 1 2 1 0 0

62% 6 5 HIGH 3 1,5 1,5 0 0 3 1 1 0 0

13% 6 2 LOW 1 5 0 0 0 0 2 0 0 0

41% 6 5 MEDIUM 2 2,5 1,5 0 0 2 2 1 0 0

-1% 8 4 NOT YET 0 0 0 8 0 0 0 0 4 0

-1% 5 3 NOT YET 0 0 0 5 0 0 0 0 3 0

-1% 8 13 NOT YET 0 0 0 8 0 0 0 0 13 0

-1% 5 5 NOT YET 0 0 0 5 0 0 0 0 5 0

-1% 6 2 NOT YET 0 0 0 6 0 0 0 0 2 0

SP 2.4 Implement the Service

System Design

SP 2.5 Integrate Service

System Components

SP 3.1 Prepare for

Verification and Validation


SP 3.3 Verify Selected Service

System Components

SP 3.4 Validate the Service

System

Service System

DevelopmentSG 1 Develop and Analyze

Stakeholder Requirements


Exemplos de Resultados Subprácticas

SP 1.1 Develop Stakeholder

Requirements

SP 1.2 Develop Service System

Requirements

SP 1.3 Analyze and Validate

Requirements

SP 2.1 Select Service System

Solutions


SP 2.3 Ensure Interface

Compatibility

SG 3 Verify and Validate Service

Systems



Tabela 4. Quadro Resumo da Área de Processo

Service System Development Fidelity

SG 1 Develop and Analyze Stakeholder Requirements MEDIUM

SP 1.1 Develop Stakeholder Requirements LOW

SP 1.2 Develop Service System Requirements MEDIUM

SP 1.3 Analyze and Validate Requirements MEDIUM

SG 2 Develop Service Systems MEDIUM

SP 2.1 Select Service System Solutions MEDIUM

SP 2.2 Develop the Design HIGH

SP 2.3 Ensure Interface Compatibility LOW

SP 2.4 Implement the Service System Design MEDIUM

SP 2.5 Integrate Service System Components NOT YET

SG 3 Verify and Validate Service Systems NOT YET

SP 3.1 Prepare for Verification and Validation NOT YET

SP 3.2 Perform Peer Reviews NOT YET

SP 3.3 Verify Selected Service System Components NOT YET

SP 3.4 Validate the Service System NOT YET

Através da tabela supra apresentada é possível observar, de forma global, o estágio no qual o

desenvolvimento do serviço se encontra. Destarte, tendo em conta os objectivos definidos pelo modelo,

o serviço de rastreios encontra-se entre a finalização do desenvolvimento do sistema de serviço e a

verificação e validação do mesmo. Por “entre” entenda-se a falta de cumprimento da última prática (SP

2.5) respectiva à integração dos componentes do sistema de serviço – a qual carece de validação da

solução para o desenho do serviço junto dos restantes stakeholders para avançar – necessários à

passagem ao objectivo final de verificação e validação do sistema de serviço, validação que ocorrerá em

“ambiente real” dada as especificidades do serviço.

Convém referir que as classificações anteriormente apresentadas mereceram a apreciação da

organização, uma vez que foram consideradas respeitadoras da realidade do serviço.

De seguida são apresentadas, em resumo, algumas considerações do primeiro objectivo (SG1).

No primeiro objectivo proposto pelo CMMI-SVC – desenvolvimento e análise dos requisitos dos

stakeholders – foram identificados alguns desvios para com as boas práticas definidas. Como resultado,

a classificação obtida na primeira prática – “LOW” – reflecte a ausência do cumprimento de subpráticas

e “exemplos de resultados” da prática, tais como: o não envolvimento dos principais stakeholders na

recolha dos seus requisitos, a inexistência de correspondência entre requisitos e stakeholders e a ténue

transformação de necessidades, expectativas e restrições dos stakeholders em requisitos (priorizados).

As restantes práticas do objectivo inicial obtiveram classificação “MEDIUM”, significando o

cumprimento de uma parte considerável das subpráticas e exemplos de resultados propostos pelo

modelo. Não obstante, é identificada uma série de desvios onde se inclui a inexistência de requisitos

derivados, a identificação explícita das interfaces do serviço e respectivas restrições e, por fim, a

ausência de validação de funcionalidades – assumidas como certas da parte dos stakeholders.



4. Recomendações ao Desenvolvimento do Sistema de Serviço

Com base no modelo de boas práticas amplamente estudado e na classificação e lacunas identificadas

através do mapeamento, foram elaboradas recomendações sucintas para o desenvolvimento do sistema

de serviço de rastreios da ARSN. Estas incidem, essencialmente, nas temáticas abordadas pelos

objectivos definidos pelo modelo – requisitos, desenho e verificação e validação do sistema de serviço.

Utilizando uma visão pragmática do conjunto de recomendações, estas foram alocadas em dois grandes

grupos: (1) Recomendações passíveis de serem realizadas no decorrer do projecto, e (2)

Recomendações a realizar em projectos futuros. Desta forma, depois de apresentadas todas as

recomendações, foi possível focar e discutir com os responsáveis da ARSN, as que em tempo útil

poderiam ser aplicadas ao projecto e daí serem retirados dividendos. É de salientar que as

recomendações elaboradas foram consideradas pela organização válidas, relevantes e pertinentes para

o projecto.

4.1. Requisitos

A realizar em projectos/programas futuros:

1. Realizar reuniões periódicas com os stakeholders para identificação de requisitos.

Passíveis de se realizar neste projecto:

2. Preparar e realizar reuniões de validação de requisitos e confirmação de pressupostos com os

stakeholders.

2.1 - Alguns requisitos podem estar especificados de forma ambígua ou incorrecta face à

inexistência de reuniões para levantamento de requisitos junto dos intervenientes.

2.2 - Muitos dos requisitos, alguns deles de importância acrescida, carecem de validação.

2.3 - Avançar o quanto antes com a reunião com ACES e CHP de modo a ser garantido e/ou

reformulado o conjunto de pressupostos e requisitos.

2.4 - Ex: Locais para acondicionamento dos kits; Assegurar existência de colaboradores; Assegurar a

colaboração do CHP – Estabelecimento do Protocolo de Cooperação.

4.2. Desenho

A realizar em projectos/programas futuros:

3. Definir de critérios em ordem à escolha de alternativas para as componentes do sistema de serviço.


4. Identificar e descrever as interfaces entre as componentes internas e externas do sistema de

serviço.

4.1 - Requisitos de interface inexistentes;

4.2 - Lista de modificações a realizar nos SI;

4.3 - Documentação interfaces.

5. Desenvolver uma estratégia para a integração de todos os componentes do sistema de serviço.

6. Formalizar acordo/comprometimento de prestação de serviço (SLA) com CHP a sua inexistência

levanta fortes problemas no desenho do sistema de rastreio.

6.1 - Assegurar a correcta comunicação de resultados – troca de informação entre o SI do CHP e o -

SiiMA Rastreios (da responsabilidade da FirstSolutions);

6.2 - Envolvimento dos colaboradores do CHP.



4.3. Verificação e Validação


7. Seguir as recomendações do modelo através do conjunto de subpráticas de verificação e validação.

7.1 - Selecção de métodos e componentes a verificar e validar – factor humano é essencial.

7.2 - Estabelecimento de critérios e procedimentos para a verificação e validação.

7.3 - Envolver colaboradores e utentes nos procedimentos de verificação e validação.

(a validação do serviço de RCCR, tendo em conta a sua especificidade, deverá acontecer em

ambiente real)

7.4 - Programar a realização das verificações e validações.

7.5 - Analisar os resultados obtidos e reflectir os mesmos através de possíveis alterações.

4.4. Relação Custo-Benefício

Após a elaboração das recomendações foi sugerido, para cada recomendação passível de ser realizada

no decorrer do projecto pela ARSN, a atribuição de custo e um benefício. A referência a custo utilizada

não possui conotação pecuniária, mas sim, um custo laboral ou de esforço organizacional. Já a

apreciação de benefício corresponde ao “valor” acrescido que poderá advir da adopção da

recomendação sugerida.

Estas classificações foram, inicialmente, atribuídas de forma meramente indicativa, sendo, em conjunto

com aos responsáveis da ARSN, solicitada a atribuição de um valor mais próximo da realidade. Foi

também pedido para ser considerado o estágio e calendário do projecto.

As classificações possíveis vão desde o nível “Baixo”, “Médio” até “Alto”, sejam elas relativas ao custo

ou ao benefício.

Tabela 5. Recomendações para o desenvolvimento e análise dos requisitos dos stakeholders (SG1)

Legenda: Passíveis de se realizar neste projecto A realizar em projectos/programas futuros

# Recomendações SG1 Prática

CMMI-SVC

R1 Realizar reuniões periódicas com os stakeholders para identificação de requisitos.

SP1.1, SP1.3

R2 Preparar e realizar reuniões de validação de requisitos e pressupostos com os stakeholders.

Alguns requisitos podem estar especificados de forma ambígua ou incorrecta face à inexistência de reuniões para levantamento de requisitos junto dos intervenientes.

Muitos dos requisitos, alguns deles de importância acrescida, carecem de validação.

Avançar o quanto antes com a reunião com ACES e CHP de modo a ser garantido e/ou reformulado o conjunto de pressupostos e requisitos.

Ex: Assegurar a existência de locais para acondicionamento dos kits; Assegurar existência de colaboradores.

SP1.1, SP1.3



R3 Priorizar requisitos. SP1.1, SP1.2

Tabela 6. Recomendações sobre o desenvolvimento do sistema de serviço (SG2)

# Recomendações SG2 Prática

CMMI-SVC

R4 Definir critérios em ordem à escolha de alternativas para as componentes do sistema de serviço.

SP2.1

R5 Identificar e descrever as interfaces entre as componentes internas e externas do sistema de serviço.

Requisitos de interface inexistentes;

Lista de modificações a realizar nos SI;

Documentação interfaces.

SP2.2, SP2.3

R6 Desenvolver uma estratégia para a integração de todos os componentes do sistema de serviço.

SP2,3, SP2.5

R7 Formalizar acordo/comprometimento de prestação de serviços (SLA) com CHP – a sua inexistência levanta fortes problemas no desenho do sistema de rastreio.

Assegurar a correcta comunicação de resultados – troca de informação entre o SI do CHP e o SiiMA Rastreios (da responsabilidade da entidade desenvolvedora);

Garantir o envolvimento dos colaboradores e serviços do CHP.

SP2.4

R8 Reformular o sistema de serviço para a seu escalamento para toda a região norte.

Neste momento o CHP surge como a solução óbvia para o projecto inicial, todavia, a replicação do serviço para além do ACES Oriental não está assegurada.

Ex: 7 dias para análise da amostra em localidades situadas fora das grandes cidades.

Poderá ser necessário realizar alguns estudos tendo em vista a replicação do serviço e reformular alguns procedimentos do rastreio face às especificidades do local.

SP1.1, SP1.2, SP1.3, SP2.1.

Na Tabela 7 é apresentada a correspondência entre as práticas do modelo CMMI-SVC e as

recomendações elaboradas, sendo de notar que as práticas com classificação “LOW” obtiveram grande

parte das correspondências (SP1.1 e SP2.3), seguidas das classificadas com “MEDIUM” e por fim “HIGH”.



Tabela 7. Correspondência entre Práticas e Recomendações elaboradas

Service System Development

Fidelity Recommendation

match

SG 1 Develop and Analyze Stakeholder Requirements

SP 1.1 Develop Stakeholder Requirements LOW

4

SP 1.2 Develop Service System Requirements MEDIUM

2

SP 1.3 Analyze and Validate Requirements MEDIUM

3


SP 2.1 Select Service System Solutions MEDIUM

2

SP 2.2 Develop the Design HIGH

1

SP 2.3 Ensure Interface Compatibility LOW 2

SP 2.4 Implement the Service System Design MEDIUM

1

SP 2.5 Integrate Service System Components NOT YET

1

SG 3 Verify and Validate Service Systems

SP 3.1 Prepare for Verification and Validation NOT YET

-

SP 3.2 Perform Peer Reviews NOT YET

-

SP 3.3 Verify Selected Service System Components NOT YET

-

SP 3.4 Validate the Service System NOT YET

-



5. Recomendações Priorizadas

Após um período de reflexão sobre as recomendações propostas, foram atribuídas classificações para o

potencial “Custo” e “Benefício” de cada recomendação. Desta forma a Tabela 8 apresenta as

recomendações priorizadas tendo em conta o rácio custo-benefício.

Lista de Recomendações Custo Benefício

1. Preparar e realizar reuniões de validação de requisitos e pressupostos com os stakeholders.

Alguns requisitos podem estar especificados de forma ambígua ou incorrecta face à inexistência de reuniões para levantamento de requisitos junto dos intervenientes.

Muitos dos requisitos, alguns deles de importância acrescida, carecem de validação.

Avançar o quanto antes com a reunião com ACES e CHP de modo a ser garantido e/ou reformulado o conjunto de pressupostos e requisitos. Ex: Assegurar a existência de locais para acondicionamento dos kits; Assegurar existência de colaboradores;

Baixo Alto

2. Identificar e descrever as interfaces entre as componentes internas e externas do sistema de serviço.

Requisitos de interface inexistentes;

Lista de modificações a realizar nos SI;

Documentação interfaces.

Médio Alto

3. Desenvolver uma estratégia para a integração de todos os componentes do sistema de serviço.

Baixo Médio

4. Formalizar acordo/comprometimento de prestação de serviço (SLA) com CHP a sua inexistência levanta fortes problemas no desenho do sistema de rastreio.

Assegurar a correcta comunicação de resultados – troca de informação entre o SI do CHP e o – SiiMA Rastreios (da responsabilidade da FirstSolutions);

Envolvimento dos colaboradores e serviços do CHP.

Alto Alto

5. Reformular o sistema de serviço para a seu escalamento para toda a região norte.

Neste momento o CHP surge como a solução óbvia para o projecto inicial, todavia, a replicação do serviço para além do ACES Oriental não está assegurada.

Ex: 7 dias para análise da amostra em localidades situadas fora das grandes cidades.

Poderá ser necessário realizar alguns estudos tendo em vista a replicação do serviço e reformular alguns procedimentos do rastreio face às especificidades do local.

Alto Alto

Tabela 8. Recomendações Priorizadas

Do trabalho realizado em conjunto com a organização chegou-se ao consenso de que, a recomendação

mais proveitosa para o projecto seria a de “Preparar e realizar reuniões de validação de requisitos e

pressupostos com os stakeholders”, uma vez que, permitirá validar requisitos e pressupostos assumidos

que poderão, ao não se confirmar, invalidar o rastreio. Do conjunto de stakeholders o Centro Hospitalar

do Porto (CHP) e o Agrupamento de Centros de Saúde (ACES) Porto Ocidental enquadravam-se como os



de maior importância – serão quem colocará o rastreio em funcionamento – pelo que foram os que

mereceram destaque.

Não obstante, as restantes recomendações mereceram igual atenção, estando programada a sua futura

adopção e implementação. Em termos práticos, não será possível, no decorrer do projecto, fazer o seu

acompanhamento.



Referências

[1] W. Hayes, Handbook for conducting Standard CMMI Appraisal Method for Process Improvement (SCAMPI) B and C appraisals, version 1.1. Pittsburgh, Pa.: Carnegie Mellon University, Software Engineering Institute, 2005.

[2] CMMI Product Team, CMMI for services, version 1.3. Pittsburgh, Pa.: Carnegie Mellon University, Software Engineering Institute, 2010.

[3] E. C. Forrester, et al., CMMI for Services : Guidelines for Superior Service. Upper Saddle River, NJ: Addison-Wesley, 2009.

[4] Vicente Moreira, "Processos Programa de Rastreio CCR," unpublished, 2011, http://paginas.fe.up.pt/~meg09027/lib/exe/fetch.php?media=wiki:ars_processos4.pdf.

http://paginas.fe.up.pt/~meg09027/lib/exe/fetch.php?media=wiki:ars_processos4.pdf



Anexo A – Componentes do Sistema de Serviço RCCR



Anexo B – Processos Serviço de Rastreio CCR



Listagem Processos-Actividades-Tarefas

P.1 - Promover Rastreio A.1.1 - Promover Programa de Rastreios

T.1.1.1 - Compilação da Informação do rastreio do cancro do cólon e recto

T.1.1.2 - Elaboração material T.1.1.3 - Formação equipas de profissionais T.1.1.4 - Informar parceiros privilegiados T.1.1.5 – Realização Campanhas de Sensibilização

CCR A.1.2 - Captação população

T.1.2.1 – Captação da População Alvo A.1.3 – Selecção dos Utentes a Convidar

T.1.3.1 – Seleccionar a população a convidar A.1.4 – Agendamento Rastreios

T.1.4.1 - Fazer agendamento dos utentes. T.1.4.2 - Envio de cartas convite personalizadas

P.2 - Controlar Rastreio A.2.1 - Verificar Não Presentes

T.2.1.1 - Verificar Utentes que não compareceram T.2.1.2 - Reagendar da consulta de 1º Atendimento T.2.1.3 - Reenvio de carta-convite T.2.1.4 - Contactar Telefonicamente utente

P.3 - Rastrear Utentes A.3.1 - Recepção População

T.3.1.1 – Assinalar a presença do utente A.3.2 - Integração Utente

T.3.2.1 - Explicação do programa do rastreio a realizar

T.3.2.2 - Verificar se o utente cumpre com os requisitos

A.3.3 - Marcação Consulta Médica T.3.3.1 - Consultar disponibilidade e agendar

consulta médica A.3.4 - Atender Utente

T.3.4.1 - Explicar procedimentos de colheita da amostra

T.3.4.2 - Entrega do dispositivo de recolha amostra (KIT)

A.3.5 - Avaliar Clinicamente o utente T.3.5.1 - Verificar detalhadamente a elegibilidade do

utente T.3.5.2 - Orientação diagnóstica ou terapêutica

A.3.6 - Recolha e Envio KIT T.3.6.1 - Recolha e Verificação das condições do KIT T.3.6.2 - Entrega de novo KIT T.3.6.3 - Rotulagem do KIT T.3.6.4 - Acondicionamento do KIT nas instalações do

UCSP T.3.6.5 - Envio do Kit para o LPC

A.3.7 - Realizar Teste PSOF T.3.7.1 - Recepção do KIT T.3.7.2 - Realização teste PSOF T.3.7.3 - Comunicação dos resultados

A.3.8 - Agendamento Consulta Hospitalar T.3.8.1 - Agendar consulta hospitalar para o utente T.3.8.2 - Envio carta com o agendamento da consulta

A.3.9 - Comunicação de Resultados T.3.9.1 – Recolha dos resultados no LPC T.3.9.2 – Reagendamento para entrega de novo Kit T.3.9.3 - Envio carta com os resultados dos pacientes

P.4 - Confirmar Rastreios Positivo A.4.1 - Consultar Utente

T.4.1.1 - Explicação do resultado do teste PSOF T.4.1.2 - Consultar disponibilidade do hospital e

agendar a videocolonoscopia T.4.1.3 - Recolha informação clínica T.4.1.4 - Entrega KIT de preparação cólon T.4.1.5 - Explicação dos procedimentos de

preparação exame A.4.2 - Realização Videocolonoscopia

T.4.2.1 - Realização da videocolonoscopia T.4.2.2– Reagendar Colonoscopia T.4.2.3 - Explicação do resultado da

videocolonoscopia T.4.2.4 - Comunicação de resultado no SiiMA-

Rastreios A.4.3 - Seguir Protocolo Sangue Oculto Positivo

T.4.3.1 – Dar seguimento ao Protocolo de PSOP T.4.3.2 – Agendar/Realizar Consulta Específica T.4.3.3 - Emissão resultados

Template para a Descrição – Processo “P3 – Rastrear Utente”

Designação Rastrear Utente

Objectivos Realização de um rastreio de base populacional, organizado, centralizado, com estreitos mecanismos de controlo e garantia de qualidade.

Assegurar o correcto rastreio aos utentes da população norte.

Garantir a recolha a protecção de dados pessoais, de acordo com os princípios do CNPD.

Articular a informação com outros SI e programas de saúde que com ele se relacionam.

Âmbito



Domínio da aplicação

O processo aplica-se a todos os rastreios ao cancro do cólon e recto a realizar no âmbito do programa de RCCR.

Limites do processo

O processo inicia-se aquando do atendimento dos utentes previamente convocados para o programa de rastreios junto da população alvo e termina com a comunicação e tratamento dos resultados do utente.

Entrada Utente Convocado

Saída Utente Rastreado e Informação tratada.

Partes interessadas

ARSN, UCSP, LPC, CHP, Utentes

Principais actividades

Recepção População, Integração Utente, Marcação Consulta Médica, Atender Utente, Avaliar Clinicamente o Utente, Recolha e Envio KIT, Realizar Teste PSOF, Agendamento Consulta Hospitalar, Comunicação de Resultados.

Interacção com outros

processos

Promover Rastreio, Controlar Rastreio

Template de Matriz de Actividade – “A.4.2 - Realização Videocolonoscopia”



Template de Instrução de Trabalho Tarefa – “T.3.7.3 – Comunicação de Resultados”

aplicaÇÃo ao sector da saÚde de modelos de boas...

Documents