Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
2
tendrán que estar especialmente acondicionadas ni dotadas para la
asistencia médica en ruta.
3
Terapéutica; hospital de día, tratamiento o Alta del Servicio de
urgencias Hospitalarias.
4
1.5. Extinguido el contrato, o la prórroga en su caso, el adjudicatario
vendrá obligado, por razones de interés público, a mantener el servicio
hasta la substanciación de un nuevo contrato. De no resultar
adjudicatario del nuevo concurso la empresa deberá mantener el
servicio de la forma que se le indique al objeto de no causar ningún tipo
de perjuicio a los usuarios del Sistema Sanitario de Euskadi.
5
2.3. Las órdenes de traslado se ajustarán a los modelos que a tal efecto
se señalen y la empresa adjudicataria, estará obligada a seguir el
circuito y protocolo de autorización que para servicio se determine. En
este ámbito, la entidad adjudicataria deberá adecuar sus sistemas para
posibilitar una integración bidireccional con la arquitectura de
Osakidetza, basada en la plataforma SOA de Oracle ( Oracle Service-
Oriented Architecture), arquitectura XML y servicios web..
6
ciudadanos objeto de cobertura y de las organizaciones de
servicios de Osakidetza del Área de Salud de Alava.
Incluirá la enumeración, descripción funcional y organizativa de
los elementos dispuestos para la atención de la demanda diaria y
semanal y con las peculiaridades asistenciales de los diferentes
tramos horarios.
Deberá contemplar las contingencias comunes en este tipo de
servicios y las alternativas para solventarlas.
Deberá contemplar los aspectos de calidad general y específicos
de los servicios de transporte.
Deberá existir al menos, un centro de coordinación ubicado en
lugar apto para gestionar la totalidad de los servicios diarios.
7
3.1.5.- El personal operativo de los vehículos de transporte
sanitario debe cumplir los requisitos exigidos por la normativa
reguladora de transporte sanitario. Dicho personal debe ir
uniformado (anexo 1) e identificado mediante la colocación de
una tarjeta en lugar visible de su ropa, en la que debe figurar el
nombre del trabajador y el de la empresa correspondiente (anexo
2).
8
previa advertencia a la empresa para su subsanación, el oportuno
trámite de imposición de penalidades.
9
3.3.2. La responsabilidad de la empresa en el traslado abarca
desde el lugar de recogida del paciente hasta su punto de destino.
Los pacientes podrán ser trasladados de un vehículo a otro
durante el recorrido, sólo en caso de accidente o avería del
mismo. En ningún caso el punto de recogida y destino podrá ser
distinto al indicado en la orden de traslado.
10
realizarse desde el propio centro, sobre todo en orden a facilitar
en lo posible la agrupación de los pacientes que deban ser
trasladados en servicios colectivos así como para facilitar la
adecuación de los recursos necesarios a las demandas previsibles
de trabajo, y todo ello al objeto de cumplir los tiempos
establecidos para la prestación de la asistencia.
11
3.3.10.2. Los itinerarios de cada ruta serán variables,
acoplándose los mismos a la localización de los centros sanitarios
de destino y al origen de los pacientes teniendo en cuenta,
además, los horarios de recogida, tratamiento y presencia de los
pacientes en los centros asistenciales correspondientes.
12
Las ambulancias deberán rotularse por la empresa adjudicataria de
acuerdo a lo especificado en el Anexo III.
5.- FACTURACIÓN
13
entre el origen y el destino del paciente, aplicando además la distancia
más corta en el trayecto según el mapa oficial de las Diputaciones
Forales o del Ministerio de Fomento.
5.6. No podrá ser facturado bajo este concierto cualquier otro servicio o
complemento que no sean las prestaciones que expresamente vienen
recogidas.
14
5.10. En el supuesto de que por parte del Departamento de Salud,
proceda el reintegro a los usuarios de los gastos por ellos soportados
como consecuencia de un servicio prestado por la empresa concertada,
el Departamento de Salud, previa comunicación a la empresa y a través
de la factura mensual, procederá a realizar las regulaciones que
pudieran resultar.
15
respecto a éste los derechos y obligaciones inherentes a su calidad de
empresario.
16
garante de la prestación
3.- Parámetros de seguimiento
Transportes sanitarios realizados por medios ajenos a la
< 0,5% 1 punto
empresa
Variaciones en los vehículos ofertados comunicadas en
< 1% 1 punto
tiempo superior a 20 días
4.- Parámetros de satisfacción
Nº de reclamaciones escritas de los
< 100/00 3 puntos
pacientes / nº de servicios
Nº de reclamaciones escritas de los centros
asistenciales / nº de servicios < 1‰ 3 puntos
17
9.1. La Delegación Territorial de Salud podrá, mediante el procedimiento
más oportuno, conocer el grado de satisfacción que manifiestan los
usuarios con relación a los servicios que presta la empresa contratada.
18
La estimación de servicios anuales para el año 2014-2019 es de,
aproximadamente, 68.500 (suma de idas y vueltas). Este número de
servicios es en todo caso orientativo (Ver Anexo IV).
19
de la empresa licitadora. Las especificaciones técnicas de
interoperabilidad figuran en el anexo V.
ANEXO I
IDENTIFICACION CORPORATIVA
PERSONAL
20
A modo de ejemplo se presenta un modelo de uniforme de acuerdo con lo
estipulado en el punto 3.4 de estas bases.
21
ANEXO II
MODELO DE TARJETA DE IDENTIFICACIÓN
A modo de ejemplo se presenta un modelo de tarjeta de identificación
externa.
ARGA
FOTO LOGO
EMPRESA
NOMBRE
NÚMERO DE IDENTIFICACI ÓN
TEKNIKARIA/TÉCNICO
AMBULANCIA NO ASISTENCIAL
ANEXO III
22
AMBULANCIAS
23
24
ANEXO IV
ESTIMACIÓN DE SERVICIOS
Total 68.543
25
ANEXO V
ESPECIFICACIONES DE INTEROPERABILIDAD. Requisitos técnicos
ÍNDICE
1 Introducción...............................................................................
3
2 Arquitectura orientada a servicios...............................................
4
2.1 Resumen de los estándares soportados
4
2.2 Requisitos funcionales
7
3 Arquitectura orientada a Eventos................................................
8
3.1 Propósito
8
3.2 Estándares de Comunicación
8
3.3 Alcance
8
3.4 Arquitectura de Event Manager
8
3.5 Mensajería. Definición de un evento
10
3.6 Publicación de eventos mediante mensajería JMS
11
3.7 Publicación de eventos mediante servicio web
12
3.8 Subscripción a eventos mediante servicio web
13
4 Anexo Servicio Mantenimiento y/o Evolución................................
15
26
Introducción
Osakidetza ha adoptado el paradigma SOA como la solución corporativa para la
integración de servicios y clientes. La arquitectura orientada a servicios (en inglés
Service Oriented Architecture), es un concepto de arquitectura de software que define
la utilización de servicios para dar soporte a los requisitos del negocio.
El siguiente documento contiene las definiciones respecto a los servicios web que
Osakidetza pondrá a disposición para que las Empresas Usuarias puedan integrarse
con los Sistemas de información de Osakidetza.
27
Arquitectura orientada a servicios
Resumen de los estándares soportados
Los estándares de comunicación soportados por la infraestructura SOA actual de
Osakidetza son:
Los Servicios Web del Servicio Osakidetza se implementarán de acuerdo con las
especificaciones WSDL v1.1, SOAP v1.1, v1.2, UDDI v2.XX y XML v1.0, esto con el
objetivo de incorporar las recomendaciones de la WS-I definidas en la especificación
Basic Profile v1.0, v2.0 y de esta manera asegurar la interoperabilidad entre los
sistemas.
28
El estándar de codificación que utilizan en los mensajes XML es UTF-8.
Existen dos versiones de la política en OWSM, una para servicios y otra para clientes.
Para garantizar la interoperabilidad, cada política tiene su versión compatible con
tecnología .NET y Java.
oracle_wss10_x509_token_with_message_sign_service_policy
oracle_wss10_x509_token_with_message_sign_service_policy_net
oracle_wss10_x509_token_with_message_sign_client_policy
oracle_wss10_x509_token_with_message_sign_client_policy_net
29
Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a
través del WAF. El WAF aplica reglas contra ataques y define patrones de
seguridad.
El OSB de internet publica los sevicios a los que pueden acceder las
aplicaciones de internet.
El OSB de internet audita todas las llamadas a los web services mediante una
política propietaria de Osakidetza gestionada por OWSM.
30
dar servicio a las peticiones que llegan desde el OSB de Internet.
La aplicación consumidora de servicios web deberá tener en cuenta que es
necesario disponer de un certificado de aplicación cliente válido para poder
invocar a los servicios web.
Las llamadas a servicios web, siempre a través del OSB dedicado para el
ámbito de Internet / DMZ, se deberán realizar mediante protocolo seguro
(HTTPS) y aplicando las políticas de seguridad WSS correspondientes a la
firma y autorización descritas.
Requisitos funcionales
A la hora de publicar un nuevo servicio, es necesario rellenar el contrato de servicio y
previo desarrollo, enviarlo a Osakidetza para su supervisión. El servicio deberá cumplir
los standares de nomenclatura y especificaciones definidas para servicios desde
Osakidetza.
Finalmente se deberá realizar la solicitud para que se efectúe el alta en el OSB de
Osakidetza.
31
Arquitectura orientada a Eventos
Propósito
Se recogen los requisitos técnicos que tienen que cumplir las aplicaciones para
publicar y/o recibir eventos del gestor corporativo de eventos de Osakidetza (Event
Manager).
Estándares de Comunicación
La mensajería del Servicio Osakidetza se implementará de acuerdo con las
especificaciones del estándar HL7 versión 2.XX o superior, o con cualquier otro
formato propio de Osakidetza y de esta manera asegurar la interoperabilidad entre los
sistemas.
Alcance
Esta información contiene información destinada los siguientes perfiles:
Event Manager se implenta sobre Oracle Service Bus desplegado sobre Oracle
WebLogic Server.
32
Figura 2.1: Arquitectura de alto nivel del gestor de eventos OSB
Este documento recoge los requisitos técnicos necesarios para que diferentes
aplicaciones y sistemas de información puedan realizar la publicación y subscripción
de eventos. La tabla siguiente contiene las diferentes tecnologías que soporta el gestor
de eventos para la publicación y subscripción a eventos, así como si la modalidad
soporta transaccionalidad y las opciones de seguridad disponibles.
recibido los
mensajes incluso
en situaciones de
error de
comunicación con
el suscriptor
Subscripción Servicio web Sí Sí. Event Manager Ninguna,
garantiza la entrega Autenticación
en el mismo orden (user/pass) y WS-
que ha Security
recibido los
mensajes
33
Mensajería. Definición de un evento
34
EventBroker-04 Unsupported subscriptor El tipo de subscriptor no es válido. Este tipo
type detected de error es interno de Event Manager y no es
común que se reproduzca porque la
asociación del tipo al subscriptor está
controlada mediante la consola de Event
Manager.
EventBroker-05 Security violation detected Error interno de Event Manager
(any security needed)
EventBroker-06 El publicador no está dado El publicador del evento indicado en el campo
de alta para este evento even:source no está autorizado para enviar el
tipo de evento indicado en el campo even:id
EventBroker-07 La publicación está Se ha deshabilitado desde la consola de
suspendida para el control de Event Manager el envío de eventos
publicador/evento para el publicador indicado en el campo
even:source o para el tipo de evento indicado
en el campo even:id
EventBroker-08 Fallo en findEventoById con No se ha encontrado el tipo de evento
id xxx: Evento no correspondiente al código de la etiqueta
encontrado even:id
EventBroker-09 No hay subscriptores No hay subscriptores configurados para el
configurados para este tipo de evento correspondiente al código de la
evento etiqueta even:id
Requisitos técnicos
Event Manager dispone de un Proxy Service que permite enviar mensajes SOAP
sobre JMS. En la siguiente tabla se muestran los requisitos por tecnología:
35
Plataforma Integración Requisitos técnicos de Réquisitos técnicos de alta
posible comunicación disponibilidad
Java J2EE Sí Ninguno.Las Ninguno.
aplicaciones J2EE se
despliegan sobre Oracle Las aplicaciones J2EE se
WebLogic Server que despliegan sobre Oracle
proporciona todo el WebLogic Server que
subsistema JMS proporciona los agentes SAF
para garantizar la alta
disponibilidad y entrega
ordenada de los mensajes
ante cualquier tipo de
contingencia.
Java standalone Sí Se requiere el uso de la La aplicación deberá de
librería wlfullclient.jar implementar un sistema que
para la comunicación garantice la alta
con Oracle WebLogic disponibilidad y la entrega
Server ordenada de los eventos ante
cualquier tipo de
contingencia.
.NET Sí Se requiere el uso de la La aplicación deberá de
librería implementar un sistema que
com.bea.weblogic.jms.d garantice la alta
otnetclient_1.3.0.0.zip disponibilidad y la entrega
para la comunicación ordenada de los eventos ante
con Oracle WebLogic cualquier tipo de
Server contingencia.
Requisitos funcionales
Es necesario rellenar el formulario de alta de publicador y hacer la solicitud para que
se efectúe el alta en Event Manager.
Requisitos técnicos
Event Manager dispone de un Proxy Service que permite enviar mensajes SOAP
sobre HTTP/HTTPS. En la siguiente tabla se muestran los requisitos por tecnología:
36
realizar llamadas SOAP que garantice la alta
sobre HTTP/HTTPS. disponibilidad y la entrega
ordenada de los eventos
ante cualquier tipo de
contingencia.
.NET Sí Se requiere el uso de las La aplicación deberá de
librerías necesarias para implementar un sistema
realizar llamadas SOAP que garantice la alta
sobre HTTP/HTTPS. disponibilidad y la entrega
ordenada de los eventos
ante cualquier tipo de
contingencia.
En cualquier caso, las aplicaciones deberán de desarrollar un cliente web service que
cumpla las especificaciones del WSDL proporcionado por Osakidetza.
Requisitos funcionales
Es necesario rellenar el formulario de alta de publicador y hacer la solicitud para que
se efectúe el alta en Event Manager.
Requisitos técnicos
Event Manager puede enviar eventos a un subscriptor mediante servicio web.
37
El servicio web publicado por el subscriptor debe implementar el WSDL
proporcionado por Osakidetza. El servicio web implementa dos operaciones:
Requisitos funcionales
Es necesario rellenar el formulario de alta de subscriptor y hacer la solicitud para que
se efectúe el alta en Event Manager. Entre otros datos, se debe de indicar la url del
web service al que Event Manager enviará los eventos.
38
Anexo Servicio Mantenimiento y/o Evolución
Se deberá de incluir este anexo en los contratos a realizar, este servicio debe consistir
en incluir los cambios de interoperabilidad que requieren un mantenimiento
permanente. Tanto evolución de los servicios web y/o eventos actuales, como de la
publicación de nuevos servicios y/o eventos y, en general, todo lo relacionado con la
interoperabilidad de los sistemas objetos del contrato.
39