PDS cambiosParametrizacionPrevision

Modernización Producto Sisalud J2EE
CÓDIGO: Página 1 de 27 Fecha de Versión: XX/XX/XXXX Versión:
Propuesta de Solución
Mejoras Parametrización Previsión
Commercial
Versión 1.1
CÓDIGO: Página 2 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1
Control de Cambios
Versió Autor Descripción del Cambio Fecha

n
1.1 Nicolás Bello Versión Inicial 30-10-2023
SONDA S.A. Copyright (c) 2022 | Prohibida su reproducción y cualquier copia impresa de este documento, se considera no controlada.
Tabla de Contenido
Control de Cambios............................................................................................................................2
Tabla de Contenido............................................................................................................................3
1 Resumen Ejecutivo..........................................................................................................................5
2 Introducción....................................................................................................................................6
2.1 Propósito del Documento........................................................................................................6
2.2 Alcance del Documento...........................................................................................................6
2.3 Audiencia Prevista....................................................................................................................6
3 Descripción del problema a resolver...............................................................................................7
4 Propuesta de Solución.....................................................................................................................8
4.1 Alternativas de Solución Analizadas.........................................................................................8
4.2 Alcances de la Solución............................................................................................................9
4.3 Solución Detallada.................................................................................................................10
4.3.1 Introducción...................................................................................................................10
4.3.2 Objetivo..........................................................................................................................10
4.3.3 Flujo del Proceso.............................................................................................................11
4.3.4 Diagrama de Estado........................................................................................................12
4.3.5 Acciones del Flujo del Proceso........................................................................................12
4.3.5.1 Personalización del Registro Previsional del Paciente.............................................12
4.3.5.2 Parametrización de Empresas – Tipo Convenio.......................................................18
4.4 Flujo De Prueba......................................................................................................................20
4.5 Trazabilidad de Requerimientos con Componentes de Trabajo.............................................20
4.6 Necesidades de Ambiente......................................................................................................21
4.6.1 Ambiente de Certificación..............................................................................................21
4.6.1.1 Hardware.................................................................................................................21
4.6.1.2 Software..................................................................................................................21
4.6.2 Ambiente Producción.....................................................................................................21
4.6.2.1 Hardware.................................................................................................................21
4.6.2.2 Software..................................................................................................................22
4.7 Criterios de Aceptación del Cliente........................................................................................22
4.8 Restricciones del Cliente........................................................................................................22
5 Plan de Trabajo.............................................................................................................................23
6 ANEXO I (Antecedentes de Pruebas).............................................................................................26

7 Anexo II (Carta al cliente de Propuesta de Solución).....................................................................27
1 Resumen Ejecutivo
No Aplica.
2 Introducción
2.1 Propósito del Documento
Este documento tiene por finalidad establecer la propuesta de solución para el cliente. La entrada
a este documento es el FDR, formulario de requerimientos.
2.2 Alcance del Documento
El alcance de este documento es cubrir todos los aspectos que debe contemplar una Propuesta de
Solución de acuerdo a los requerimientos funcionales y no funcionales.
2.3 Audiencia Prevista
Rol Nombre
CL: Cliente Sonda Vertical Salud
GP: Gerente de Proyecto Nadia Vega
JP: Jefe de Proyecto Flavia Ballejos
LT: Líder Técnico Flavia Ballejos
AN: Analista Nicolás Bello
CON: Contraparte Requerido
TESTER: Interno, Externo
GC: Gestor de la Sonda Vertical Salud

Configuración
DES: Desarrollador
STK: Stakeholders
3 Descripción del problema a resolver

En el marco de la modernización del Sistema HIS en el aplicativo de SISALUD, tenemos el desafío
de estandarizar la aplicación para que esta responda a las necesidades clínicas y administrativas de
las organizaciones prestadoras de salud de manera globalizada.
En esta sección, se presenta de manera detallada y precisa el problema que necesita ser abordado
para mejorar la eficiencia y la adaptabilidad del sistema en el contexto de la atención médica y
administrativa. La descripción se divide en dos aspectos fundamentales:
Adaptabilidad del Registro Previsional del Paciente:
El problema que debemos enfrentar en este aspecto del proyecto se relaciona con la necesidad de
adaptar y personalizar el registro previsional del paciente de acuerdo al "holding" de la sesión en
uso. Específicamente, debemos señalar que es esencial ocultar el control llamado "Usa Previsión"
en las páginas del aplicativo cuando este dato resulta redundante o no aporta valor. Esto es
especialmente relevante en organizaciones de salud ubicadas en países donde las regulaciones
exigen invariablemente la existencia de una entidad promotora de salud. La falta de
personalización conduce a una ineficiencia en el registro administrativo, obligando a los usuarios a
completar datos irrelevantes, lo que resulta en una pérdida significativa de tiempo y un uso poco
efectivo del sistema.
Categorización de Empresas:
El segundo aspecto del problema se centra en la necesidad de categorizar los tipos de previsión
que las empresas en la aplicación puedan disponer, existiendo la posibilidad de que estás puedan
ser categorizadas por más de un tipo de previsión según el "holding" al que esté asociada la
empresa-cliente. Hoy en día, existen varios tipos de categorías como organizaciones promotoras
de salud, empresas de seguro, convenios empresariales, medicinas pre-pagadas y seguros
complementarios, entre otros, y la aplicación solo puede relacionar una empresa-cliente a una
sola categoría. La falta de una solución adecuada para esta categorización afecta directamente la
operatividad y eficiencia del aplicativo, así como la satisfacción de los usuarios que buscan un
registro ágil de los tipos de Previsión relacionados con los clientes-empresas para una adecuada
valorización de los servicios de salud según corresponda.
La solución a los problemas descritos no solo mejorará la experiencia de los usuarios al reducir la
carga de trabajo administrativo innecesario, sino que también contribuirá a la eficiencia operativa
y estratégica de las organizaciones de salud al garantizar que el registro de información se ajuste
de manera precisa a las particularidades de cada contexto. Por tanto, es esencial abordar este
problema de manera oportuna y efectiva en un contexto de modernización y globalización del
Sistema HIS como producto donde es imperativo cumplir con estándares de adaptabilidad a
diferentes regulaciones y requisitos normativos de las organizaciones prestadoras de salud en
diversos países.
4 Propuesta de Solución
4.1 Alternativas de Solución Analizadas
Alternativa de Solución para la Personalización del Registro Previsional del Paciente:

Para abordar la problemática de personalización del registro previsional del paciente en el
aplicativo de SISALUD, proponemos la implementación de un parámetro de configuración
denominado "FormaValorizacionCta". Este parámetro será diseñado y aplicado de manera
específica con el propósito de abordar la necesidad de ocultar el control "Usa Previsión" en las
páginas pertinentes, considerando el contexto y las regulaciones normativas vigentes de las
organizaciones prestadoras de salud.
El parámetro "FormaValorizacionCta" ofrecerá una parametrización altamente flexible. Los
administradores del sistema tendrán la capacidad de definir y aplicar la configuración especifica
del parámetro que determinará cuándo el control "Usa Previsión" debe mostrarse y cuándo debe
permanecer oculto. Esta flexibilidad permitirá la adaptación en tiempo real del aplicativo a las
particularidades de cada organización de salud y a las sesiones de usuario, garantizando así el
cumplimiento de las regulaciones normativas de manera eficiente y precisa.
Alternativa de Solución para la Categorización de Empresas:
En cuanto a la problemática relacionada con la múltiple parametrización de Tipos de Previsión
para las empresas-clientes en la aplicación, proponemos el desarrollo de una pantalla de
configuración especializada. Esta pantalla permitirá la parametrización de diversos Tipos de
Previsión definidas por el modelo de salud de cada organización y que podrán ser relacionadas con
las empresas-clientes que se deseen configurar en la sección de parametrización, teniendo la
posibilidad de relacionar más de un Tipo de previsión para cada empresa. Esto garantizará una
gestión eficiente de la información y una adaptabilidad óptima del sistema a las particularidades
de cada entidad de salud y sus requisitos de categorización.
Estas alternativas de solución se enfocan en la implementación de herramientas técnicas y
configurables que optimizarán la personalización del sistema, asegurando así una mejor respuesta
a las necesidades clínicas y administrativas de las organizaciones prestadoras de salud.
4.2 Alcances de la Solución
El alcance de la solución propuesta se limita sólo al contenido en esta propuesta. Cualquier

actividad o desarrollo no contemplado, debe ser evaluado como un control de cambio adicional al
proyecto.
4.3 Solución Detallada
4.3.1 Introducción
En el contexto de la modernización del Sistema HIS para su globalización como un producto

versátil y adaptable a las necesidades clínicas y administrativas de las organizaciones prestadoras
de salud, se plantea una modificación fundamental.
La primera problemática presentada en esta propuesta se relaciona con la necesidad de
personalizar el registro previsional del paciente, adaptándolo al contexto específico de las sesiones
en uso y a las regulaciones normativas de las organizaciones de salud. Esta adaptabilidad es
esencial para eliminar la redundancia de datos y mejorar la eficiencia en el registro administrativo.
La segunda problemática, aborda la parametrización de múltiples Tipos de Previsión para las
empresas-clientes en la aplicación. Dado que las organizaciones de salud pueden ser categorizadas
de diversas maneras, es necesario desarrollar un sistema que permita configurar y relacionar estas
categorías de manera efectiva.
En esta propuesta de solución, presentaremos en detalle dos alternativas técnicamente sólidas
para abordar estas problemáticas. La primera alternativa propone la implementación del
parámetro de configuración "FormaValorizacionCta" para personalizar el registro previsional del
paciente. La segunda alternativa se enfoca en desarrollar una pantalla de configuración que
permitirá la parametrización de Tipos de Previsión y su relación con las empresas-clientes.
Estas soluciones se centran en mejorar la eficiencia operativa y la adaptabilidad del Sistema
administrativo de Salud en el aplicativo de SISALUD, garantizando así una respuesta precisa a las
necesidades específicas de las organizaciones prestadoras de salud y el cumplimiento de
regulaciones normativas. En este documento, presentaremos en detalle estas alternativas,
destacando su aplicabilidad y los beneficios que aportarán a la modernización y globalización de
nuestro sistema, asegurando una experiencia más satisfactoria para nuestros usuarios y clientes.
Continuemos ahora con la descripción detallada de estas soluciones propuestas, brindando una
visión completa de su implementación y funcionamiento.
4.3.2 Objetivo
El objetivo principal de esta propuesta de solución es abordar de manera efectiva y técnica las
problemáticas relacionadas con la personalización del registro previsional del paciente y la
parametrización de Tipos de Previsión para las empresas-cliente en el aplicativo de SISALUD.
Nuestro propósito es proporcionar soluciones que permitan mejorar la eficiencia operativa y la
adaptabilidad del Sistema SISALUD, garantizando que responda de manera precisa a las
necesidades clínicas y administrativas de las organizaciones prestadoras de salud, cumpliendo con
regulaciones normativas y requisitos específicos.
En otras palabras, contribuir a la modernización y globalización del Sistema SISALUD, brindando

una experiencia más satisfactoria a los usuarios y clientes, y asegurando la adaptabilidad a las
regulaciones y requisitos normativos de las organizaciones prestadoras de salud en diversos
contextos.
4.3.3 Flujo del Proceso
En la ilustración, se presenta el flujo de procesos que aborda la aplicación SISALUD. La realización

de cambios en la captura de la previsión del paciente afectará directamente a varios módulos
clave, los cuales incluyen:
 Admisión Hospitalaria.
 Admisión Urgencia.
 Admisión Transitoria.
 Nueva Cuenta (Asomeduc).
 Revalorización de la cuenta.
 Comprobante Ambulatorio.
En el proceso inicial, al generar una admisión, ya sea en el ámbito hospitalario, de urgencia o
transitorio, se realiza la captura de la previsión del paciente. El botón "Usa Previsión" habilita la
obtención de un listado pre-filtrado de las instituciones previsionales. Cuando se activa el control
"Usa Previsión," se permite la selección entre diferentes tipos de financiadores, como Isapre o
Fonasa. En caso de que el control permanezca inactivo, el tipo de financiador se restringe a solo
“particular”.
La posibilidad de crear una nueva cuenta al consultar las cuentas corrientes de los pacientes
mantiene este mismo control durante la captura de datos de previsión.
Asimismo, la captura de datos de previsión juega un papel relevante al revalorizar una cuenta y en
la generación de comprobantes ambulatorios.
Además, este control, aparte de quedar oculto en las pantallas anteriormente mencionadas debe
quedar constantemente activado.
Por lo tanto, dado este flujo de trabajo integral, es esencial realizar modificaciones en ciertas
pantallas. Estas modificaciones, en resumen, se llevarán a cabo mediante la implementación de un
parámetro que permitirá ajustar el control de acuerdo al "holding" que lo requiera de manera
específica y así mismo también ocupará el mismo parámetro para las lógicas que lo mantendrán
activado.
Por otro lado, la parametrización de la empresa cliente no confluye en un proceso como tal. Sin
embargo, la parametrización de la empresa cliente como Tipo de previsión es muy relevante para
los procesos de valorización.
4.3.4 Diagrama de Estado
No Aplica.
4.3.5 Acciones del Flujo del Proceso
4.3.5.1 Personalización del Registro Previsional del Paciente
Durante En el proceso de admisión hospitalaria, uno de los elementos clave que se capturan son
los datos de la previsión del paciente. Estos datos están directamente vinculados a un control
denominado "Usa Previsión," el cual filtra los tipos de previsión en función de la actividad. Cuando
este control está activado, es decir, seleccionado en la opción "Sí," el campo de tipo de previsión
ofrece la posibilidad de elegir entre dos opciones: Isapres o Fonasa.
No obstante, si la opción del control es "No," el campo de tipo de previsión se restringe
únicamente a la categoría "Particular."
Es importante destacar que mantener este control invariable en "Holdings" donde la opción por
defecto es siempre "Sí" de acuerdo a las regulaciones, puede llevar a que el control carezca de
utilidad y, en algunos casos, incluso obstaculice el proceso de captura de información en la
admisión.
Por lo tanto, es fundamental que este control sea adaptable al "holding" específico. Por ejemplo,
en el contexto de Chile, podríamos necesitar que el control esté presente para mejorar la
eficiencia en la captura de información. Sin embargo, en un escenario opuesto, como el de

Colombia, donde los pacientes deben tener, por defecto, al menos una previsión de tipo EPS, el
control podría considerarse redundante en el sistema como se puede apreciar en la siguiente
imagen del levantamiento de los campos de utilidad en la parametrización previsional del
paciente, donde el control “Usa Previsión” no es una categorización relevante en la página o
páginas de “COLOMBIA”.
A continuación, se indican las ubicaciones de los controles resaltados en color rojo para cada uno
de los módulos encargados de la captura de la previsión del paciente:
 Admisión Hospitalaria (ADM_Hospitalizacion)
 Admisión Transitoria (ADM_AmbulatoriaTransitoria)
 Admisión de Urgencia (ADM_AdmAmbuUrg)
 Botón Nueva Cuenta (CTANvaCtaIngRapido)
 Revalorización (CTARevalorizarCta)
 Comprobante Ambulatorio (COPIngComprobanteCaja)
Con el fin de lograr la adaptabilidad de la interfaz según el "holding" de trabajo, se implementará

un parámetro de función denominado "FormaValorizaCta." La función principal de este parámetro
será ocultar el control "Usa Previsión" y asignar el valor = ‘true’ al control por defecto, esto debe
ser aplicado de acuerdo al “holding” especifico de la sesión.
En consecuencia, a través de un desarrollo en el código, se establecerá, mediante un parámetro de

entrada de la sesión y una serie de lógicas definidas, si es necesario ocultar o no el control. Los
detalles técnicos y la implementación de este desarrollo se describirán de manera minuciosa en
los documentos de diseño y arquitectura correspondientes.
Cabe destacar, que este parámetro no solo será de utilidad para el control especifico, sino que
será de utilidad para parametrizar todos los controles que se deseen ocultar en la aplicación a
medida que se vayan ajustando las parametrizaciones y el desarrollo de la aplicación se vaya

adaptando a los diferentes contextos de operatividad.
4.3.5.2 Parametrización de Empresas – Tipo Convenio
En detalle, la propuesta de solución para poder parametrizar los Tipos de Previsión para las
empresas, consiste en desarrollar una página que se encuentre dentro del módulo de
parametrización de Empresa-Cliente que permita la categorización en uno o más Tipos de
Previsión correspondientes a las asociaciones que puedan ofrecer a los clientes como previsión en
el modelo de salud de acuerdo al contexto en el que se esté operando la aplicación.
A continuación, se muestra y navegará un prototipo no funcional de la página de configuración a
desarrollar:
La página anterior, corresponde a la parametrización de Empresa-Cliente. En particular se realizó

la búsqueda de la Empresa-Cliente para EPS Famisanar que, para este ejemplo corresponde a una
aseguradora para el país de Colombia, donde ésta tendría diferentes tipos de Previsión que
ofrecer.
Dicho lo anterior, es que la propuesta de solución, de acuerdo con la siguiente imagen, cumpliría
con la función que se detallará a continuación.
La principal función de esta pantalla a desarrollar es poder atribuir distintos tipos de Previsión a
una empresa cliente. Por lo tanto, al entrar a esta pestaña de configuración, se presentará un
combo-box donde podemos elegir los tipos de previsión vigentes.
Luego el usuario podrá configurar según desee los tipos de Previsión que pueda o estime
conveniente deba ofrecer la empresa. Si el usuario se equivoca al realizar la configuración, tiene la
opción de eliminar el registro. De lo contrario, de ser correcta la configuración tiene la posibilidad
de grabar los cambios al volver a la página anterior, permitiendo una parametrización correcta y
completa de los datos de previsión de la correspondiente empresa.
4.4 Flujo De Prueba
No Aplica.
4.5 Trazabilidad de Requerimientos con Componentes de

Trabajo
ID Requerimiento Componentes
Requerimient
o
NEC.01 Sistema de Salud  Admisión Hospitalaria.

- Admisión  Admisión Urgencia.
- Cuenta  Admisión Transitoria.
- Valorización  Nueva Cuenta (Asomeduc).
 Revalorización de la cuenta.
 Comprobante Ambulatorio.
NEC.02 Sistema de Salud  Tabla nueva

- Parametrización o NetTipPrevisionEmpres
o Empresa a
 Métodos para la carga del
combo-box
o SvcNetTipPrevisionB
NEC.03 Parametrización  Página nueva

- Empresa o CLI_TipoPrevisionEmpr
o CLI_TipoPrevisionEmpr esa
esa
4.6 Necesidades de Ambiente
4.6.1 Ambiente de Certificación
[El propósito de éste apartado es especificar las necesidades requeridas para habilitar el ambiente
de pruebas, en caso de que esto se encuentre especificado en otro artefacto, y corresponde
efectivamente a lo requerido por los ejecutores del testing, puede indicar el link desde donde se
puede obtener esa información, en caso contrario, ésta debe ser detallada en ésta sección. En el
caso de las implantaciones se puede detallar directamente en este ítem las necesidades de
ambiente sin necesidad de utilizar los ítems 4.3.1.1 Y 4.3.1.2]
4.6.1.1 Hardware
[Describir a continuación los elementos de Hardware requeridos para realizar el Testing]
[Nota: El texto encerrado en [ ] y resaltado en amarillo, representa una guía para el autor y debe
ser eliminado antes de publicar el documento].
4.6.1.2 Software
[Describir a continuación los elementos de Software requeridos para realizar el Testing]
4.6.2 Ambiente Producción
[El propósito de éste apartado es especificar las necesidades requeridas por el cliente para
habilitar la solución]
4.6.2.1 Hardware
[Describir a continuación los elementos de Hardware requeridos para instalar la solución].
4.6.2.2 Software
[Describir a continuación los elementos de Hardware requeridos para instalar la solución.]
4.7 Criterios de Aceptación del Cliente
[Describa los criterios de aceptación por parte del cliente, también se deben describir los Estados
de pago que vayan asociados al desarrollo para que se reflejen en los criterios de aceptación]
4.8 Restricciones del Cliente
[Describa las restricciones del cliente para que la funcionalidad propuesta opere en forma
correcta. Ver Formulario de Requerimientos.
Describa las restricciones del cliente para que la funcionalidad propuesta opere en forma correcta.
Las restricciones deben estar acorde con las restricciones descritas en el Formulario de
Requerimientos.doc.
Como ejemplo se pueden considerar restricciones de:
 Plazo de entrega
 Regulación de entidades como SBIF, SAF, Banco Central, otras.
 La empresa proveedora del software tenga certificación ISO o CMMI
 Para la generación de los procedimientos almacenados no se pueden utilizar cursores
 Comunicación hacia otras entidades que forman parte del ambiente del cliente]
5 Plan de Trabajo
[IMPORTANTE: Para el artefacto PDS “Plan de Trabajo”, el cronograma de actividades es de uso
optativo, sin embargo el cuadro resumen es obligatorio cuando la Contraparte sea Interna, y
optativo cuando la Contraparte sea Externa. Junto con lo anterior queda a criterio del Jefe de
Proyecto si dentro del cuadro resumen se detalla el esfuerzo (en Horas Hombre o meses
Hombre), monto (UF, $) o desglosa la cotización inicial.]
[ACTIVIDAD WBS o desglose de elementos definibles en elementos administrables, que sirve como
marco de trabajo del proyecto.
RECUERDA: Trabajo que no esté incluido dentro de la WBS está fuera del alcance de la solución.
Mejores prácticas para construir una WBS inicial:
 Verificar si hay registros históricos de proyectos similares.

 Identificar los principales componentes y actividades términos de resultados tangibles y
verificables de manera que se facilite la evaluación del rendimiento.
 Decidir si un estimativo adecuado de costo y duración puede ser desarrollado a este nivel
de detalle para cada componente o actividad.
 Verificar el grado de veracidad de la descomposición.
A continuación se entrega una propuesta de actividades mínimas a realizar]

ACTIVIDAD HH
Análisis
Analizar situación actual HH

Rol responsable de documentar Analista
Documentar situación actual.
Analizar alternativas de solución HH

Documentar alternativas de solución.
Preparar solución propuesta HH

Documentar la solución propuesta.
Estimar trabajo a realizar HH

Presentar solución propuesta HH
Rol responsable de coordinar la reunión Analista
Ajustes a la solución propuesta HH

Diseño
Detallar diseño funcional HH

Completar la especificación funcional de la solución.
Preparar diseño físico.
Detallar pruebas funcionales HH

Preparar test de aceptación para validar que la solución satisface el requerimiento
documentado.
Construcción
Desarrollar la solución HH
Rol responsable de coordinar y supervisar: Analista.
Rol responsable de ejecutar el desarrollo: Desarrollador.
Generar cada componente de acuerdo a los criterios de diseño especificados.
Pruebas Unitarias HH
Probar cada componente de forma unitaria e integrada al resto de la aplicación.
Preparar la lista de componentes para entregar a testing.
Enviar la solicitud de pruebas a testing.
Pruebas
Pruebas de Aceptación SONDA HH

Rol responsable de coordinar Analista.
Rol responsable de apoyar las pruebas Desarrollador.
Rol responsable de ejecutar las pruebas Testeador.
Preparar las pruebas de aceptación en SONDA.
Registrar, revisar y corregir la solución para defectos identificados y los resultados
obtenidos.
Obtener la aceptación del Jefe de Proyecto.
Instalación
Instalar y homologar HH
Rol responsable Analista.
Preparar y entregar la Acta de entrega, donde estas las componentes a instalar.
Instalar las componentes de la solución en el cliente.
Homologar las componentes de la solución en el cliente.
Pruebas de Aceptación HH
Rol responsable de coordinar Jefe de Proyecto.
Rol responsable de apoyar las pruebas Analista.
Preparar las pruebas de aceptación en el cliente.

Registrar, revisar y corregir la solución para defectos identificados y los resultados
obtenidos.
Obtener la aceptación del cliente.
Entregar la propiedad de la solución al cliente.
[ACTIVIDAD: El siguiente cuadro resumen permite al Jefe de Proyecto tener una visión Global del
esfuerzo estimado en la solución del requerimiento.]
Cuadro Resumen
Análisis
Diseño
Construcción
Pruebas
Instalación
Total HH
6 ANEXO I (Antecedentes de Pruebas)

[El presente capitulo tiene por objetivo mencionar los documentos anexos y/o descripciones
especiales que complementen las pruebas. En caso de no existir información anexa, el capítulo no
debe ser eliminado del documento, indicar explícitamente que No aplica el anexo a este
documento].
7 Anexo II (Carta al cliente de Propuesta de Solución)

[La propuesta de solución debe ser presentada a través de un medio formal (mail, carta), se
propone el siguiente formato para presentarla. En caso de no existir información anexa, el capítulo
no debe ser eliminado del documento, indicar explícitamente que No aplica el anexo a este
documento].
[Recordar que esta carta propuesta debe ser eliminada del documento]
Folio:
Santiago, dd de mm de
aaaa
Señor:
Nombre contacto
Cargo contacto
Institución
Presente.
De nuestra consideración,
Junto con saludarle, hacemos llegar a Ud. nuestra propuesta de solución para
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Quedamos atentos a responder sus observaciones y a su completa disposición para reunirnos con
el objetivo de profundizar en la discusión de la solución propuesta.
Le saluda muy atentamente,
Nombre representante de SONDA

Cargo del representante
SONDA S.A.
DIVISION/UNIDAD/DEPARTAMENTO

PDS cambiosParametrizacionPrevision

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PDS cambiosParametrizacionPrevision

Cargado por

Copyright:

Formatos disponibles

Modernización Producto Sisalud J2EE

CÓDIGO: Página 1 de 27 Fecha de Versión: XX/XX/XXXX Versión:

CÓDIGO: Página 2 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

Versió Autor Descripción del Cambio Fecha

1.1 Nicolás Bello Versión Inicial 30-10-2023

CÓDIGO: Página 3 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

CÓDIGO: Página 4 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

6 ANEXO I (Antecedentes de Pruebas).............................................................................................26

CÓDIGO: Página 5 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

CÓDIGO: Página 6 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

2.1 Propósito del Documento

2.2 Alcance del Documento

2.3 Audiencia Prevista

CL: Cliente Sonda Vertical Salud

GP: Gerente de Proyecto Nadia Vega

JP: Jefe de Proyecto Flavia Ballejos

LT: Líder Técnico Flavia Ballejos

AN: Analista Nicolás Bello

CON: Contraparte Requerido

TESTER: Interno, Externo

GC: Gestor de la Sonda Vertical Salud

CÓDIGO: Página 7 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

3 Descripción del problema a resolver

Adaptabilidad del Registro Previsional del Paciente:

CÓDIGO: Página 8 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

4.1 Alternativas de Solución Analizadas

Alternativa de Solución para la Personalización del Registro Previsional del Paciente:

CÓDIGO: Página 9 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

4.2 Alcances de la Solución

El alcance de la solución propuesta se limita sólo al contenido en esta propuesta. Cualquier

CÓDIGO: Página 10 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

4.3 Solución Detallada

En el contexto de la modernización del Sistema HIS para su globalización como un producto

CÓDIGO: Página 11 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

En otras palabras, contribuir a la modernización y globalización del Sistema SISALUD, brindando

4.3.3 Flujo del Proceso

En la ilustración, se presenta el flujo de procesos que aborda la aplicación SISALUD. La realización

CÓDIGO: Página 12 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

4.3.4 Diagrama de Estado

4.3.5 Acciones del Flujo del Proceso

4.3.5.1 Personalización del Registro Previsional del Paciente

CÓDIGO: Página 13 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

eficiencia en la captura de información. Sin embargo, en un escenario opuesto, como el de

CÓDIGO: Página 14 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

 Admisión Hospitalaria (ADM_Hospitalizacion)

CÓDIGO: Página 15 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

 Admisión Transitoria (ADM_AmbulatoriaTransitoria)

CÓDIGO: Página 16 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

 Admisión de Urgencia (ADM_AdmAmbuUrg)

 Botón Nueva Cuenta (CTANvaCtaIngRapido)

CÓDIGO: Página 17 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

 Comprobante Ambulatorio (COPIngComprobanteCaja)

Con el fin de lograr la adaptabilidad de la interfaz según el "holding" de trabajo, se implementará

En consecuencia, a través de un desarrollo en el código, se establecerá, mediante un parámetro de

CÓDIGO: Página 18 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

medida que se vayan ajustando las parametrizaciones y el desarrollo de la aplicación se vaya

4.3.5.2 Parametrización de Empresas – Tipo Convenio

La página anterior, corresponde a la parametrización de Empresa-Cliente. En particular se realizó

CÓDIGO: Página 19 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

CÓDIGO: Página 20 de 27 Fecha de Versión: XX/XX/XXXX Versión: 1.1

4.4 Flujo De Prueba

4.5 Trazabilidad de Requerimientos con Componentes de

NEC.01 Sistema de Salud  Admisión Hospitalaria.