Particularidades de la nueva release:

Receta digital PBA

Una vez deployada la nueva versión se debe actualizar el template de receta, caso contrario no se podrán generar nuevas.

Esta acción es necesaria debido a que modificó un método que genera pdfs para agregar un parámetro y por lo tanto la receta se vio afectada.

Historia Clinica

No refiere alergias

A partir de ahora, un usuario con rol especialista médico y en odontología tiene la posibilidad de dejar registro de que le consultó al paciente sobre la existencia de una alergia y este le indicó que no posee ninguna.

Para esto, dentro del desplegable “Alergias”, se agregó un checkbox de “No refiere” al lado del botón principal de “+ Agregar alergia” donde el usuario puede indicar que no refiere ninguna alergia.


En caso de seleccionar este checkbox, el botón principal de “+ Agregar alergia” queda disabled. 


Análogo en caso de cargarle una alergia al paciente

.

Esta funcionalidad está presente en los documentos de:

  1. Nota de evolución de guardia
  2. Consulta ambulatoria
  3. Nota de evolución de internación
  4. Anamnesis (Evaluación de ingreso)
  5. Consulta odontológica

Cabe mencionar que en caso de seleccionar “No refiere”, esto solo queda registrado en el documento en cuestión y no en la solapa “RESUMEN” de la HC del paciente ya que este puede indicar que no posee ninguna pero luego se le encuentra una alergia. 

No refiere antecedentes personales y familiares

A partir de ahora el usuario especialista médico y en odontología tiene la posibilidad de dejar registro de que le preguntó al paciente sobre la existencia de antecedentes personales o familiares y este le indicó que no posee ninguno.

Dentro del desplegable “Antecedentes personales” y “Antecedentes familiares”, se agregó un checkbox de “No refiere” al lado del botón principal de “+ Agregar antecedente personal” y “+ Agregar antecedente familiar”, donde el usuario puede indicar que no refiere ningún antecedente.


En caso de seleccionar este checkbox, el botón principal de “+ Agregar antecedente personal” o “+ Agregar antecedente familiar” quedará disabled.


Análogo en caso de cargarle un antecedente al paciente.


Esta funcionalidad está presente en los documentos de:

  1. Nota de evolución de guardia
  2. Consulta ambulatoria
  3. Anamnesis (Evaluación de ingreso)
  4. Consulta odontológica

Cabe mencionar que en caso de seleccionar “No refiere”, esto solo queda registrado en el documento en cuestión y no en la solapa “RESUMEN” de la HC del paciente ya que este puede indicar que no posee ninguno pero luego se le encuentra un antecedente. 

Histórico documentos de internación-evaluación de ingreso

A partir de ahora, todos los campos completados en el documento evaluación de ingreso por parte del especialista médico o el especialista en odontología se muestran en la vista previa del documento dentro del histórico de evoluciones.

El nuevo formato cuenta con un encabezado donde se visualiza los siguientes datos del documento:

  • Ambito
  • Especialidad
  • Fecha y hora
  • Profesional
  • Institucion
  • Sector
  • Sala
  • Cama

Con respecto a los campos completados tienen el siguiente formato:


Reporte atenciones de guardia

Todo usuario con acceso a los reportes de hoja 2 y 2.1, tiene acceso a un nuevo reporte que muestra información resumida de las consultas de guardia. El nombre del mismo debe es: 

”Reporte detalle nominal atenciones de guardia”.

El reporte muestra información resumida de las atenciones de guardia. El mismo se genera a partir de ciertos filtros iniciales, donde el filtro obligatorio es la fecha inicial. Los filtros del reporte serán:

  • Tipo de unidad jerárquica
  • Unidad jerarquica
  • Incluir descendientes
  • Fecha de inicio
  • Fecha de fin (sólo visualización)
  • Profesional

Una vez generado el reporte, este cuenta con un header con los siguientes datos:

  • Número de Hoja
  • Establecimiento (nombre del establecimiento desde el que se genera el reporte)
  • Mes (Número de mes del parámetro fecha de inicio)
  • Año (Número de año del parámetro fecha de inicio)
  • Partido   (nombre del partido al que pertenece el establecimiento desde el que se genera el reporte)
  • Región sanitaria 
  • Servicio 

Los columnas del reporte son:

  • Provincia 
  • Municipio
  • Cod_Establecimiento
  • Establecimiento
  • Tipo de unidad jerárquica
  • Unidad jerárquica 
  • Apellido paciente 
  • Nombre paciente 
  • Nombre autopercibido 
  • ID Paciente HSI
  • Tipo Documento 
  • Nro documento 
  • Fecha de nacimiento 
  • Edad 
  • Sexo documento 
  • Género autopercibido 
  • Barrio 
  • Domicilio 
  • Teléfono 
  • Mail 
  • Obra social/Prepaga asociada episodio 
  • Obra social/Prepaga del paciente
  • Nro de afiliado
  • Id episodio
  • Hora de apertura del episodio 
  • Usuario creador episodio 
  • Tipo de guardia 
  • Fecha y hora último triage 
  • Cantidad triages episodio 
  • Tipo de triage 
  • Estado del episodio 
  • Fecha y hora atención 
  • Lugar atención
  • Motivo 
  • Diagnóstico 
  • Fecha y hora alta médica 
  • Práctica/procedimientos 
  • Usuario triage 
  • Profesional consulta 
  • Profesional alta médica 
  • Pases de 
  • Tipo de egreso

Reprogramación de turnos-sobreturnos

A partir de este release, se pueden reasignar turnos como sobreturnos en slots donde ya existen turnos asignados siempre y cuando la franja permita la asignación de sobreturnos. Luego de que el usuario ingresa al detalle del turno puede hacer click sobre el botón “Editar fecha y hora del turno”.


Después de esto, el usuario debe seleccionar la modalidad, la fecha y la hora. Las opciones que se visualizaban antes eran espacios en donde no existía ningún turno asignado, es decir, el slot estaba completamente libre sin importar si se permitían o no sobreturnos en el slot. A partir de ahora, el flujo de reasignación se mantiene igual pero se permite reasignar el turno en slots de franjas donde ya hay turnos asignados y tienen permitido la asignación de sobreturnos. 


Edición de documento de guardia

A partir del release 2.22, los usuarios con permisos para crear documentos “nota de evolución de guardia” tienen la posibilidad de editar el documento luego de confirmarlo. 

Esta acción deja registro de la información del usuario, la fecha de creación y guarda el documento para su posterior edición y/o cierre.

Para realizar esto, el usuario visualiza un botón de editar dentro de la vista previa del documento en el histórico de evoluciones del episodio de guardia.


En caso de hacer click sobre el botón de “Editar” se le muestra al usuario el popup de la nota de evolución de guardia con los datos precargados de la última versión. Aquí, puede visualizar, agregar o quitar componentes y volver a guardar la nota de evolución de guardia nuevamente. El usuario asociado a la nota de evolución de guardia será el último que la confirme.

Cabe mencionar que:

  • Todos los datos son posibles de editar.
  • No debe completar el motivo por el cual editó el documento.
  • La edición estará disponible hasta el alta administrativa.
  • La nota de evolución de guardia puede ser editada por cualquier profesional con acceso de edición de episodio de guardia.
  • Si el que editó la nota de evolución, no posee la especialidad que se usó para la creación, entonces se setea la primera especialidad del profesional. De lo contrario, se carga la especialidad de la creación.

Percentiles

Cuando un usuario con permiso de visualizar los datos antropométricos del paciente tiene acceso a ver los gráficos de curva de crecimiento se encontraban con los percentiles de un paciente nacido a término. El desarrollo que se realizó es mostrarle un mensaje de advertencia que no se encuentra considerado en los gráficos a los pacientes prematuros.

El usuario ingresa a la historia clínica del paciente en donde hay un card con los datos antropométricos y tiene la opción por medio de un botón de ingresar a ver los gráficos. Al presionarlo se muestra el siguiente popup con el mensaje:

“Los gráficos presentados están destinados a pacientes nacidos a término y no incluyen casos de nacimientos prematuros.”

Reportes – Detalle nominal de atenciones en Guardia

Se creó un nuevo reporte que brinda información nominalizada de las atenciones de la guardia.

Particularidades:

  • Con respecto al filtro fecha, solo se puede definir la fecha inicial y la fecha final son 7 días posteriores a la fecha definida como inicial sin posibilidad de cambiarla. 
  • Filtro profesional: permitirá filtrar por el profesional que puso el episodio en atención por última vez.
  • El filtro de fecha representa la fecha de inicio del episodio
  • Para la edad, si el paciente tiene menos de 1 año la misma se visualiza  en meses, caso contrario en años.
  • Lugar de atención, en caso de que el episodio se atienda en un Shockroom o en un Consultorio se visualiza el nombre del mismo, en caso de que se atienda en una habitación se visualiza [nombre de habitación – número de cama]

Columnas que muestra el reporte:

  • Provincia (nombre de la provincia del establecimiento desde el que se genera el reporte)
  • Municipio (nombre del municipio del establecimiento desde el que se genera el reporte)
  • Cod_Establecimiento (Código SISA del establecimiento desde el que se genera el reporte)
  • Establecimiento (nombre del establecimiento desde el que se genera el reporte)
  • Tipo de unidad jerárquica (nombre del tipo de la unidad jerárquica del sector en el cual fue atendido por última vez el episodio)
  • Unidad jerárquica (nombre de la unidad jerárquica del sector en el cual fue atendido por última vez el episodio)
  • Apellido paciente (primer apellido + otros apellidos del paciente atendido en el episodio)
  • Nombre paciente (primer nombre+ otros nombres del paciente atendido en el episodio)
  • Nombre autopercibido (nombre autopercibido del paciente atendido en el episodio. Este dato podría estar vacío)
  • ID Paciente HSI
  • Tipo Documento (descripción del tipo de documento del paciente atendido en el episodio. Este dato podría estar vacío)
  • Nro documento (número de documento del paciente atendido en el episodio. Este dato podría estar vacío)
  • Fecha de nacimiento  (fecha de nacimiento del paciente atendido en el episodio. Este dato podría estar vacío. Formato dd/mm/yyyy)
  • Edad (edad del paciente atendido al momento de la atención)
  • Sexo documento (descripción del sexo del documento del paciente atendido en el episodio. Este dato podría estar vacío)
  • Género autopercibido (descripción del género autopercibido del paciente atendido en el episodio. Este dato podría estar vacío)
  • Barrio (barrio del domicilio del paciente atendido en el episodio. Este dato podría estar vacío)
  • Domicilio (domicilio del paciente atendido en el episodio. Este dato podría estar vacío. No considerar barrio)
  • Teléfono (teléfono del paciente atendido en el episodio. Este dato podría estar vacío. Prefijo+teléfono)
  • Mail (mail del paciente atendido en el episodio. Este dato podría estar vacío)
  • Obra social/Prepaga asociada episodio (nombre de la cobertura definida en el episodio. Este dato podría estar vacío)
  • Obra social/Prepaga del paciente(nombre de todas las coberturas activas del paciente del episodio, separadas por comas. Este dato podría estar vacío)
  • Nro de afiliado (nro de afiliado de la cobertura definida en el episodio. Este dato podría estar vacío)
  • Id episodio
  • Hora de apertura del episodio (hora del ingreso administrativo del episodio. Formato hh:mi)
  • Usuario creador episodio (nombre y apellido completo del usuario que realiza el ingreso administrativo: apellido+otros apellidos nombre+otros nombres o nombre autopercibido según corresponda)
  • Tipo de guardia (nombre del tipo de guardia. Podría estar vacío o tomar los valores Adulto, Pediatría o Ginecología y obstetricia)
  • Fecha y hora último triage (Podría estar vacío. Formato dd/mm/yyyy hh:mi)
  • Cantidad triages episodio (Podría estar vacío)
  • Tipo de triage (Descripción del nivel de urgencia del último triage. Podría estar vacío)
  • Estado del episodio (Descripción del estado del episodio al momento de la realización del reporte: En espera, En atención, Con alta médica, Con alta administrativa)
  • Fecha y hora atención (se toma el momento cuando el usuario hace click sobre el boton atender por ultima vez. Podria estar vacío. Formato dd/mm/yyyy hh:mi)
  • Lugar de atención(Descripción del último lugar de atención del episodio. Podría estar vacío)
  • Motivo (Lista de descripciones de motivos de consulta definidos en el episodio, separado por comas si corresponde. Podría estar vacío)
  • Diagnóstico (Lista de descripciones de todos los diagnósticos asociados al episodio, separados por comas si corresponde. Podría estar vacío)
  • Fecha y hora alta médica (Podría estar vacío. Formato dd/mm/yyyy hh:mi)
  • Práctica/procedimientos (listado de los nombres de procedimientos que se agregan en la/s nota/s de evolución y también los estudios finalizados solicitados durante el episodio de guardia. Podría estar vacío)
  • Usuario triage (nombre y apellido completo del usuario que realiza el último triage: apellido+otros apellidos+ nombre+otros nombres o nombre autopercibido según corresponda. Podría estar vacío)
  • Profesional consulta (nombre y apellido completo del usuario  que hace click sobre el botón atender por última vez: apellido+otros apellidos+ nombre+otros nombres o nombre autopercibido según corresponda. Podría estar vacío)
  • Profesional alta médica (nombre y apellido completo del usuario  que hace alta médica: apellido+otros apellidos + nombre+otros nombres o nombre autopercibido según corresponda. Podría estar vacío)
  • Pases de (Corresponde a la cantidad de pases de lugares de atención dentro de la guardia. Podría estar vacío)
  • Tipo de egreso (Descripción del tipo de egreso definido en el alta médica. Podría estar vacío)

API Publica – Reportes estadísticos-Turnos de consulta o práctica

Se nos solicitó un endpoint en la API pública que devuelva información de turnos de agenda.

Nombre: FetchConsultationsByDate

Permisos: Rol API_REPORTES con su api-key relacionada

Parámetros

Request params

  • dateFrom: fecha desde la cual se filtra (obligatorio)
  • dateUntil: fecha hasta la cual se filtra (obligatorio, no puede estar separada por más de 30 días de dateFrom)
  • institutionRefsetCode: código refset/sisa de la institución por la que se desea filtrar (opcional)
  • hierarchicalUnitId: identificador de la unidad jerárquica por la que se filtra (opcional, debe ser de tipo Servicio)

Datos que arroja el endpoint:

  • idTurno—siempre tendrá valor
  • idConsulta–puede ser null
  • Fecha
  • idEfector (código sisa de la institución)
  • Efector (nombre de institución)
  • idServicio
    • Si existe consulta, corresponde al id de la uj asociado a esta, sino al id de la uj asociado a la agenda.
    • Representa id de uj, solo si es de tipo servicio, sino buscamos el primer padre de tipo servicio y seteamos ese id
  • Servicio (alias de la uj)
  • IdServicioSector (IdSubservicio)
    • Mismo criterio que el punto anterior. Si existe consulta, corresponde al id de la uj asociado a esta, sino seria el id de la uj asociado a la agenda.
    • Este id podría pertenecer a una UJ que no es de tipo servicio
    • Este identificador puede ser el mismo que el de idServicio, en caso de que la UJ no posea “padre” y a su vez sea de tipo servicio.
  • ServicioSector (alias de la uj)
  • CodEspecialidad (código snomed de la especialidad) Cod snomed de la especialidad de la consulta, si no existe, de la agenda
  • Especialidad (descripción snomed de la especialidad de la agenda) Descripción snomed de la especialidad de la consulta, si no existe, de la agenda.
  • TipoDocumentoPaciente (descripción del tipo de documento del paciente) Cuando es una reserva online (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • NúmeroDocumentoPaciente
  • Financiador (descripción de  la cobertura asociado a la consulta) Cuando es una reserva online (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • RNOSFinanciador Cuando es una reserva online (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • SexoOficial (descripcion del sexo del documento)
  • FechaNacimiento (fecha de nacimiento del paciente en formato YYYY-MM-DD)
  • Edad (edad de paciente al momento de la consulta)—si no hay consulta, campo en null
  • Departamento (descripcion del partido que figura en el dato de empadronamiento del paciente) Cuando es una reserva online (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • Distrito (descripcion de la ciudad que figura en el dato de empadronamiento del paciente) Cuando es una reserva online (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • EstadoTurno (descripción del estado del turno)
  • CanalObtención (Presencial o “Turnos online”)
  • Motivos
  • Procedimientos
  • Problemas

Formato de respuesta

Si existe una persona asociada al usuario, la respuesta será:

[

  {

    “appointmentId”: 0,

    “consultationId”: 0, 

    “consultationDate”: {

      “date”: {

        “year”: 0,

        “month”: 0,

        “day”: 0

      },

      “time”: {

        “hours”: 23,

        “minutes”: 59,

        “seconds”: 59

      }

    },

    “institutionCode”: “string”,

    “institutionName”: “string”,

    “serviceHierarchicalUnit”: {

      “id”: 0,

      “description”: “string”,

      “type”: 0

    },

    “hierarchicalUnit”: {

      “id”: 0,

      “description”: “string”,

      “type”: 0

    },

    “clinicalSpecialty”: {

      “id”: 0,

      “description”: “string”,

      “snomedId”: “string”

    },

    “identification”: {

      “identificationType”: “string”,

      “identificationNumber”: “string”

    },

    “medicalCoverage”: {

      “name”: “string”,

      “rnos”: 0

    },

    “officialGender”: “string”,

    “birthdate”: {

      “year”: 0,

      “month”: 0,

      “day”: 0

    },

    “age”: 0,

    “department”: “string”,

    “city”: “string”,

    “appointmentState”: “string”,

    “appointmentBookingChannel”: “string”,

    “reasons”: [

      {

        “sctId”: “string”,

        “pt”: “string”,

        “cie10Id”: “string”,

        “startDate”: “2024-05-15”,

        “endDate”: “2024-05-15”

      }

    ],

    “procedures”: [

      {

        “sctId”: “string”,

        “pt”: “string”,

        “cie10Id”: “string”,

        “startDate”: “2024-05-15”,

        “endDate”: “2024-05-15”

      }

    ],

    “problems”: [

      {

        “sctId”: “string”,

        “pt”: “string”,

        “cie10Id”: “string”,

        “startDate”: “2024-05-15”,

        “endDate”: “2024-05-15”

      }

    ]

  }

]

Mensajes de error

400 invalid-date si la fecha no está en formato yyyy-mm-dd
400 Constraint violation si el rango de fechas excede los 30 días
401 unauthorized si el api-key no se corresponde con un usuario con rol API_REPORTES
404 institution-not-exists si el sisa (refset) code no existe

Bugs y mejoras

Visualización de header solapada de documento de Parte Quirúrgico

Se nos reportó en release anterior que al descargar el parte quirúrgico, el header del mismo se veía solapado con el cuerpo del documento

Este inconveniente fue resuelto en esta nueva release

Filtro en evoluciones de internación

Se nos había reportado que al ingresar al histórico de evoluciones de un paciente internado, en componente campo seleccionar tipo de documento y ahí clickear tipo de documento, solo se listan: Evaluación de ingreso, Nota de evolución, Nota de evolución de enfermería, y Epicrisis (duplicado)

Este inconveniente fue resuelto en esta nueva versión

Pacientes – Informes – Anexo II sale en blanco

Nos reportaron que al descargar desde paciente, informes, un tipo de archivo anexo ll, el mismo se visualizaba en blanco.

Este bug fue fixeado para esta nueva versión.

Impresion de historia clínica – información de epicrisis

Se nos pidió respetar el orden de la información de los datos registrados en la epicrisis al momento de generar la impresión de historia clinica.

Problemas para realizar una solicitud de referencia en consulta odontológica

Se nos reportó un error al intentar generar una solicitud de referencia desde una consulta odontológica.

Acceso a usuarios para el Rol Administrador Acceso Dominio en Backoffice

Nos reportaron que el rol administrador de acceso de dominio no tenía acceso a ver usuarios desde el backoffice para luego otorgar permisos para gestionar el control de acceso a los reguladores. Este inconveniente fue fixeado en esta nueva release.

Este error fue resuelto en esta nueva release.