Servicio de salud que ofrece una organización en una o varias ubicaciones: una consulta externa de cardiología, un servicio de emergencias, un laboratorio clínico, un servicio de resonancia magnética. Se modela con el recurso HealthcareService de FHIR R5 y completa el registro de establecimientos de OpenHIE (IHE mCSD) como directorio de servicios.

Código interno con que la organización identifica el servicio en sus sistemas (por ejemplo, el código de un servicio en la agenda de citas).

Regla de negocio: Opcional. No hay un catálogo nacional de servicios de establecimientos.

Regla de validación: No puede haber dos ocurrencias con el mismo establecimiento y código. Invariante cr-identificador-unico (compartida por la ubicación, el rol, el servicio y la relación entre organizaciones): `identifier.select(system & '

Permite que la agenda de citas, el expediente y el directorio se refieran al mismo servicio. Es opcional porque no hay un catálogo nacional de servicios.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Código del servicio en el sistema de la organización.

Regla de negocio: Lo define cada organización.

Regla de validación: De 1 a 64 caracteres, sin espacios. Invariante cr-codigo-interno-value: matches('^\\S{1,64}$').

Es el valor con que el sistema de la organización reconoce el servicio.

Código del establecimiento que asignó el código.

Regla de negocio: Es el codigo-establecimiento de la organización o, si es una unidad sin identificador propio, el de su organización superior.

Regla de validación: Invariante cr-servicio-system: system.matches('^https://hl7\\.or\\.cr/fhir/sid/servicio/(cj-[1-9][0-9]{9}|cn-[1-9][0-9]{8}|dimex-[1-9][0-9]{10,11})$').

Cada organización numera sus servicios por su cuenta. El establecimiento hace único el código, igual que en el expediente del paciente.

Organización que ofrece el servicio y responde por él.

Regla de negocio: Obligatoria. Es la organización más específica: el hospital o el EBAIS, no la CCSS. Si el servicio lo presta otra organización por contrato (una relación entre organizaciones de compra de servicios), la organización es la que lo presta, no la que lo compra.

Regla de validación: Referencia a un Organization activo que cumpla el modelo de organización.

Es quien presta el servicio y responde por él, también cuando lo presta por contrato para otra organización.

Lugares donde se presta el servicio: la sede o el espacio dentro de ella.

Regla de negocio: Obligatoria: en esta versión todos los servicios son presenciales (la telemedicina queda fuera, igual que en la ubicación). Cada ubicación debe pertenecer a la organización del servicio. Se recomienda la ubicación más específica (el servicio de radiología, no toda la sede).

Regla de validación: Referencias a Location que cumplan el modelo de ubicación.

Comentarios: La dirección y la posición geográfica del servicio son las de su sede, por la jerarquía de la ubicación; así funciona la búsqueda por cercanía.

Dice a dónde debe ir el paciente para recibir el servicio. Es obligatoria porque en esta versión todos los servicios son presenciales.

Nombre con que el establecimiento presenta el servicio al público.

Regla de negocio: Por ejemplo, Consulta externa de cardiología, Emergencias, Laboratorio clínico.

Regla de validación: Longitud de 2 a 250 caracteres.

Es como el paciente y quien refiere reconocen el servicio, por ejemplo Consulta externa de cardiología.

Qué servicio se ofrece. Valores iniciales en el catálogo tipo de servicio de salud.

Regla de negocio: Obligatorio. Un servicio puede tener varios tipos (por ejemplo, un servicio de emergencias que también hace cirugía ambulatoria). La especialidad (cardiología, pediatría) no va aquí sino en especialidad.

Regla de validación: Debe pertenecer al catálogo tipo de servicio de salud. Si ningún concepto corresponde, se registra con su texto (binding extensible).

Comentarios: El catálogo es multisectorial: describe la función del servicio, no la forma en que una institución organiza sus servicios, y aplica igual a la CCSS, al INS, a los establecimientos privados y a otros prestadores como la Cruz Roja (pregunta 1).

Permite buscar qué servicios hay y dónde, con un catálogo común a los sectores público y privado (decisión 1). Es lo que consulta un sistema para saber a dónde referir.

Especialidades del servicio (por ejemplo, cardiología en una consulta especializada).

Regla de negocio: Obligatoria si el tipo de servicio es consulta-especializada; opcional en los demás.

Regla de validación: Debe pertenecer al catálogo especialidad en salud. Invariante cr-servicio-especialidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'consulta-especializada').exists() implies specialty.exists().

Comentarios: El catálogo está pendiente de los colegios profesionales (pregunta 4 del profesional de salud).

Permite encontrar una consulta de una especialidad concreta, por ejemplo cardiología, sin que el catálogo de tipos de servicio tenga que repetir cada especialidad.

Modalidades de imagen que ofrece un servicio de imágenes médicas. Ejemplos: tomografía computarizada (CT), resonancia magnética (MR), ultrasonido (US), mamografía (MG), radiografía digital (DX), radiografía computarizada (CR), medicina nuclear (NM), tomografía por emisión de positrones (PT), angiografía (XA), fluoroscopía (RF).

Regla de negocio: Solo se registra si el tipo de servicio es imagenes-medicas, y en ese caso es obligatoria. Permite buscar dónde hay un equipo determinado, por ejemplo dónde hay resonancia magnética.

Regla de validación: Debe pertenecer al ValueSet DICOM de modalidades (CID 33). Invariante cr-servicio-modalidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'imagenes-medicas').exists() = characteristic.coding.where(system = 'http://dicom.nema.org/resources/ontology/DCM').exists().

Comentarios: Es el mismo código de modalidad que llevará el estudio en la IG de informes de imágenes médicas (ImagingStudy.modality). DICOM es de uso libre, sin licencia.

Permite buscar dónde hay un equipo determinado, por ejemplo una resonancia magnética, con los códigos DICOM que ya usan los equipos y los sistemas de imágenes.

Qué necesita el paciente para usar el servicio. Valores: 1. Referencia de otro servicio o nivel de atención (referencia) 2. Orden de un profesional (orden-medica) 3. Cobertura o derecho a la atención (cobertura): seguro de salud de la CCSS, póliza del INS o de una aseguradora privada, o plan de la organización

Regla de negocio: Opcional: sin requisitos, el servicio es de acceso directo (por ejemplo, emergencias o vacunación). Por ejemplo, en la red de la CCSS las consultas especializadas suelen requerir referencia y cobertura (el seguro de salud); un hospital privado puede requerir cobertura de una póliza determinada, y los servicios de apoyo diagnóstico, en cualquier sector, orden-medica. Qué cobertura se acepta se detalla en eligibility.comment (por ejemplo, "Seguro de salud de la CCSS" o "Pólizas de gastos médicos del INS").

Regla de validación: Debe pertenecer al catálogo requisito de acceso. Un requisito que no esté en la lista (por ejemplo, una edad mínima) se registra con su texto en eligibility.code.text y el detalle en eligibility.comment (binding extensible).

Comentarios: No sustituye la verificación del derecho a la atención en cada caso, que se hará con el modelo de cobertura (pregunta 12 del paciente).

Dice qué necesita el paciente para usar el servicio (referencia, orden médica, cobertura), para que quien refiere lo prepare antes y el paciente no llegue sin él.

Indica si el servicio se atiende solo con cita previa.

Regla de negocio: Opcional. Si no se registra, no se sabe; no se supone que no requiere cita.

Evita que el paciente se presente sin cita en un servicio que solo atiende con cita previa.

Idiomas en que se puede atender en el servicio, además del español.

Regla de negocio: Opcional. Útil para el turismo médico y para las poblaciones indígenas.

Regla de validación: Código BCP 47.

Permite encontrar un servicio que atienda en otro idioma, para el turismo médico y las poblaciones indígenas.

Días y horas en que se ofrece el servicio. Cada ocurrencia es un bloque de días con el mismo horario.

Regla de negocio: Opcional. Un servicio con horarios distintos según el día lleva varias ocurrencias (por ejemplo, lunes a viernes de 7:00 a 16:00 y sábados de 7:00 a 12:00). Un servicio de 24 horas lleva todos los días con todoElDia. Las horas son de Costa Rica (UTC−6, sin horario de verano).

Regla de validación: Cada bloque se registra con todoElDia o con horaInicio y horaFin, no las dos cosas, y la hora de inicio es anterior a la de fin. Invariante cr-servicio-horario sobre availableTime.

Comentarios: Es el primer modelo que incluye horario: la ubicación y el rol del profesional lo dejaron fuera hasta que un caso de uso lo necesitara, y el directorio de servicios lo necesita (pregunta 4).

Dice cuándo se puede usar el servicio. El directorio de servicios lo necesita para referir o enviar al paciente en un horario en que lo atiendan (decisión 4).

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Días de la semana del bloque. Valores: mon, tue, wed, thu, fri, sat, sun.

Regla de validación: Debe pertenecer al ValueSet HL7 days-of-week.

Indica a qué días de la semana aplica el bloque de horario.

Indica que el servicio atiende las 24 horas en esos días.

Regla de validación: Ver la regla del horario.

Distingue un servicio de 24 horas, como emergencias, sin tener que dar las horas de inicio y fin.

Hora en que empieza la atención, en hora de Costa Rica.

Regla de validación: Formato hh:mm:ss, anterior a la hora de fin (invariante cr-servicio-horario).

Marca desde qué hora se atiende en esos días.

Hora en que termina la atención, en hora de Costa Rica.

Regla de negocio: Un horario que pasa la medianoche (por ejemplo, de 22:00 a 6:00) se registra como dos bloques.

Regla de validación: Formato hh:mm:ss, posterior a la hora de inicio (invariante cr-servicio-horario).

Marca hasta qué hora se atiende en esos días.

Teléfono del servicio (por ejemplo, para solicitar citas).

Regla de negocio: Opcional. Si no se registra, se usa el de la ubicación o el de la organización.

Regla de validación: Igual que en el paciente; la extensión interna va después de ;ext= (RFC 3966).

Permite al paciente o a quien refiere pedir una cita o hacer una consulta directamente al servicio.

Correo del servicio.

Regla de negocio: Opcional.

Regla de validación: Igual que en el paciente.

Sirve para las comunicaciones formales con el servicio.

Información adicional para el paciente o para quien refiere: preparación previa, avisos temporales, detalles del servicio.

Regla de negocio: Por ejemplo, Presentarse en ayunas de 8 horas o Resonador en mantenimiento hasta el 15 de octubre.

Regla de validación: Longitud máxima de 1000 caracteres.

Avisa de lo que el paciente o quien refiere debe saber y no cabe en otro dato: una preparación previa o un cierre temporal.

Servicio de salud que ofrece una organización en una o varias ubicaciones: una consulta externa de cardiología, un servicio de emergencias, un laboratorio clínico, un servicio de resonancia magnética. Se modela con el recurso HealthcareService de FHIR R5 y completa el registro de establecimientos de OpenHIE (IHE mCSD) como directorio de servicios.

Código interno con que la organización identifica el servicio en sus sistemas (por ejemplo, el código de un servicio en la agenda de citas).

Regla de negocio: Opcional. No hay un catálogo nacional de servicios de establecimientos.

Regla de validación: No puede haber dos ocurrencias con el mismo establecimiento y código. Invariante cr-identificador-unico (compartida por la ubicación, el rol, el servicio y la relación entre organizaciones): `identifier.select(system & '

Permite que la agenda de citas, el expediente y el directorio se refieran al mismo servicio. Es opcional porque no hay un catálogo nacional de servicios.

Código del servicio en el sistema de la organización.

Regla de negocio: Lo define cada organización.

Regla de validación: De 1 a 64 caracteres, sin espacios. Invariante cr-codigo-interno-value: matches('^\\S{1,64}$').

Es el valor con que el sistema de la organización reconoce el servicio.

Código del establecimiento que asignó el código.

Regla de negocio: Es el codigo-establecimiento de la organización o, si es una unidad sin identificador propio, el de su organización superior.

Regla de validación: Invariante cr-servicio-system: system.matches('^https://hl7\\.or\\.cr/fhir/sid/servicio/(cj-[1-9][0-9]{9}|cn-[1-9][0-9]{8}|dimex-[1-9][0-9]{10,11})$').

Cada organización numera sus servicios por su cuenta. El establecimiento hace único el código, igual que en el expediente del paciente.

Organización que ofrece el servicio y responde por él.

Regla de negocio: Obligatoria. Es la organización más específica: el hospital o el EBAIS, no la CCSS. Si el servicio lo presta otra organización por contrato (una relación entre organizaciones de compra de servicios), la organización es la que lo presta, no la que lo compra.

Regla de validación: Referencia a un Organization activo que cumpla el modelo de organización.

Es quien presta el servicio y responde por él, también cuando lo presta por contrato para otra organización.

Lugares donde se presta el servicio: la sede o el espacio dentro de ella.

Regla de negocio: Obligatoria: en esta versión todos los servicios son presenciales (la telemedicina queda fuera, igual que en la ubicación). Cada ubicación debe pertenecer a la organización del servicio. Se recomienda la ubicación más específica (el servicio de radiología, no toda la sede).

Regla de validación: Referencias a Location que cumplan el modelo de ubicación.

Comentarios: La dirección y la posición geográfica del servicio son las de su sede, por la jerarquía de la ubicación; así funciona la búsqueda por cercanía.

Dice a dónde debe ir el paciente para recibir el servicio. Es obligatoria porque en esta versión todos los servicios son presenciales.

Nombre con que el establecimiento presenta el servicio al público.

Regla de negocio: Por ejemplo, Consulta externa de cardiología, Emergencias, Laboratorio clínico.

Regla de validación: Longitud de 2 a 250 caracteres.

Es como el paciente y quien refiere reconocen el servicio, por ejemplo Consulta externa de cardiología.

Qué servicio se ofrece. Valores iniciales en el catálogo tipo de servicio de salud.

Regla de negocio: Obligatorio. Un servicio puede tener varios tipos (por ejemplo, un servicio de emergencias que también hace cirugía ambulatoria). La especialidad (cardiología, pediatría) no va aquí sino en especialidad.

Regla de validación: Debe pertenecer al catálogo tipo de servicio de salud. Si ningún concepto corresponde, se registra con su texto (binding extensible).

Comentarios: El catálogo es multisectorial: describe la función del servicio, no la forma en que una institución organiza sus servicios, y aplica igual a la CCSS, al INS, a los establecimientos privados y a otros prestadores como la Cruz Roja (pregunta 1).

Permite buscar qué servicios hay y dónde, con un catálogo común a los sectores público y privado (decisión 1). Es lo que consulta un sistema para saber a dónde referir.

Especialidades del servicio (por ejemplo, cardiología en una consulta especializada).

Regla de negocio: Obligatoria si el tipo de servicio es consulta-especializada; opcional en los demás.

Regla de validación: Debe pertenecer al catálogo especialidad en salud. Invariante cr-servicio-especialidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'consulta-especializada').exists() implies specialty.exists().

Comentarios: El catálogo está pendiente de los colegios profesionales (pregunta 4 del profesional de salud).

Permite encontrar una consulta de una especialidad concreta, por ejemplo cardiología, sin que el catálogo de tipos de servicio tenga que repetir cada especialidad.

Modalidades de imagen que ofrece un servicio de imágenes médicas. Ejemplos: tomografía computarizada (CT), resonancia magnética (MR), ultrasonido (US), mamografía (MG), radiografía digital (DX), radiografía computarizada (CR), medicina nuclear (NM), tomografía por emisión de positrones (PT), angiografía (XA), fluoroscopía (RF).

Regla de negocio: Solo se registra si el tipo de servicio es imagenes-medicas, y en ese caso es obligatoria. Permite buscar dónde hay un equipo determinado, por ejemplo dónde hay resonancia magnética.

Regla de validación: Debe pertenecer al ValueSet DICOM de modalidades (CID 33). Invariante cr-servicio-modalidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'imagenes-medicas').exists() = characteristic.coding.where(system = 'http://dicom.nema.org/resources/ontology/DCM').exists().

Comentarios: Es el mismo código de modalidad que llevará el estudio en la IG de informes de imágenes médicas (ImagingStudy.modality). DICOM es de uso libre, sin licencia.

Permite buscar dónde hay un equipo determinado, por ejemplo una resonancia magnética, con los códigos DICOM que ya usan los equipos y los sistemas de imágenes.

Qué necesita el paciente para usar el servicio. Valores: 1. Referencia de otro servicio o nivel de atención (referencia) 2. Orden de un profesional (orden-medica) 3. Cobertura o derecho a la atención (cobertura): seguro de salud de la CCSS, póliza del INS o de una aseguradora privada, o plan de la organización

Regla de negocio: Opcional: sin requisitos, el servicio es de acceso directo (por ejemplo, emergencias o vacunación). Por ejemplo, en la red de la CCSS las consultas especializadas suelen requerir referencia y cobertura (el seguro de salud); un hospital privado puede requerir cobertura de una póliza determinada, y los servicios de apoyo diagnóstico, en cualquier sector, orden-medica. Qué cobertura se acepta se detalla en eligibility.comment (por ejemplo, "Seguro de salud de la CCSS" o "Pólizas de gastos médicos del INS").

Regla de validación: Debe pertenecer al catálogo requisito de acceso. Un requisito que no esté en la lista (por ejemplo, una edad mínima) se registra con su texto en eligibility.code.text y el detalle en eligibility.comment (binding extensible).

Comentarios: No sustituye la verificación del derecho a la atención en cada caso, que se hará con el modelo de cobertura (pregunta 12 del paciente).

Dice qué necesita el paciente para usar el servicio (referencia, orden médica, cobertura), para que quien refiere lo prepare antes y el paciente no llegue sin él.

Indica si el servicio se atiende solo con cita previa.

Regla de negocio: Opcional. Si no se registra, no se sabe; no se supone que no requiere cita.

Evita que el paciente se presente sin cita en un servicio que solo atiende con cita previa.

Idiomas en que se puede atender en el servicio, además del español.

Regla de negocio: Opcional. Útil para el turismo médico y para las poblaciones indígenas.

Regla de validación: Código BCP 47.

Permite encontrar un servicio que atienda en otro idioma, para el turismo médico y las poblaciones indígenas.

Días y horas en que se ofrece el servicio. Cada ocurrencia es un bloque de días con el mismo horario.

Regla de negocio: Opcional. Un servicio con horarios distintos según el día lleva varias ocurrencias (por ejemplo, lunes a viernes de 7:00 a 16:00 y sábados de 7:00 a 12:00). Un servicio de 24 horas lleva todos los días con todoElDia. Las horas son de Costa Rica (UTC−6, sin horario de verano).

Regla de validación: Cada bloque se registra con todoElDia o con horaInicio y horaFin, no las dos cosas, y la hora de inicio es anterior a la de fin. Invariante cr-servicio-horario sobre availableTime.

Comentarios: Es el primer modelo que incluye horario: la ubicación y el rol del profesional lo dejaron fuera hasta que un caso de uso lo necesitara, y el directorio de servicios lo necesita (pregunta 4).

Dice cuándo se puede usar el servicio. El directorio de servicios lo necesita para referir o enviar al paciente en un horario en que lo atiendan (decisión 4).

Días de la semana del bloque. Valores: mon, tue, wed, thu, fri, sat, sun.

Regla de validación: Debe pertenecer al ValueSet HL7 days-of-week.

Indica a qué días de la semana aplica el bloque de horario.

Indica que el servicio atiende las 24 horas en esos días.

Regla de validación: Ver la regla del horario.

Distingue un servicio de 24 horas, como emergencias, sin tener que dar las horas de inicio y fin.

Hora en que empieza la atención, en hora de Costa Rica.

Regla de validación: Formato hh:mm:ss, anterior a la hora de fin (invariante cr-servicio-horario).

Marca desde qué hora se atiende en esos días.

Hora en que termina la atención, en hora de Costa Rica.

Regla de negocio: Un horario que pasa la medianoche (por ejemplo, de 22:00 a 6:00) se registra como dos bloques.

Regla de validación: Formato hh:mm:ss, posterior a la hora de inicio (invariante cr-servicio-horario).

Marca hasta qué hora se atiende en esos días.

Teléfono del servicio (por ejemplo, para solicitar citas).

Regla de negocio: Opcional. Si no se registra, se usa el de la ubicación o el de la organización.

Regla de validación: Igual que en el paciente; la extensión interna va después de ;ext= (RFC 3966).

Permite al paciente o a quien refiere pedir una cita o hacer una consulta directamente al servicio.

Correo del servicio.

Regla de negocio: Opcional.

Regla de validación: Igual que en el paciente.

Sirve para las comunicaciones formales con el servicio.

Información adicional para el paciente o para quien refiere: preparación previa, avisos temporales, detalles del servicio.

Regla de negocio: Por ejemplo, Presentarse en ayunas de 8 horas o Resonador en mantenimiento hasta el 15 de octubre.

Regla de validación: Longitud máxima de 1000 caracteres.

Avisa de lo que el paciente o quien refiere debe saber y no cabe en otro dato: una preparación previa o un cierre temporal.

Servicio de salud que ofrece una organización en una o varias ubicaciones: una consulta externa de cardiología, un servicio de emergencias, un laboratorio clínico, un servicio de resonancia magnética. Se modela con el recurso HealthcareService de FHIR R5 y completa el registro de establecimientos de OpenHIE (IHE mCSD) como directorio de servicios.

Código interno con que la organización identifica el servicio en sus sistemas (por ejemplo, el código de un servicio en la agenda de citas).

Regla de negocio: Opcional. No hay un catálogo nacional de servicios de establecimientos.

Regla de validación: No puede haber dos ocurrencias con el mismo establecimiento y código. Invariante cr-identificador-unico (compartida por la ubicación, el rol, el servicio y la relación entre organizaciones): `identifier.select(system & '

Permite que la agenda de citas, el expediente y el directorio se refieran al mismo servicio. Es opcional porque no hay un catálogo nacional de servicios.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Código del servicio en el sistema de la organización.

Regla de negocio: Lo define cada organización.

Regla de validación: De 1 a 64 caracteres, sin espacios. Invariante cr-codigo-interno-value: matches('^\\S{1,64}$').

Es el valor con que el sistema de la organización reconoce el servicio.

Código del establecimiento que asignó el código.

Regla de negocio: Es el codigo-establecimiento de la organización o, si es una unidad sin identificador propio, el de su organización superior.

Regla de validación: Invariante cr-servicio-system: system.matches('^https://hl7\\.or\\.cr/fhir/sid/servicio/(cj-[1-9][0-9]{9}|cn-[1-9][0-9]{8}|dimex-[1-9][0-9]{10,11})$').

Cada organización numera sus servicios por su cuenta. El establecimiento hace único el código, igual que en el expediente del paciente.

Organización que ofrece el servicio y responde por él.

Regla de negocio: Obligatoria. Es la organización más específica: el hospital o el EBAIS, no la CCSS. Si el servicio lo presta otra organización por contrato (una relación entre organizaciones de compra de servicios), la organización es la que lo presta, no la que lo compra.

Regla de validación: Referencia a un Organization activo que cumpla el modelo de organización.

Es quien presta el servicio y responde por él, también cuando lo presta por contrato para otra organización.

Lugares donde se presta el servicio: la sede o el espacio dentro de ella.

Regla de negocio: Obligatoria: en esta versión todos los servicios son presenciales (la telemedicina queda fuera, igual que en la ubicación). Cada ubicación debe pertenecer a la organización del servicio. Se recomienda la ubicación más específica (el servicio de radiología, no toda la sede).

Regla de validación: Referencias a Location que cumplan el modelo de ubicación.

Comentarios: La dirección y la posición geográfica del servicio son las de su sede, por la jerarquía de la ubicación; así funciona la búsqueda por cercanía.

Dice a dónde debe ir el paciente para recibir el servicio. Es obligatoria porque en esta versión todos los servicios son presenciales.

Nombre con que el establecimiento presenta el servicio al público.

Regla de negocio: Por ejemplo, Consulta externa de cardiología, Emergencias, Laboratorio clínico.

Regla de validación: Longitud de 2 a 250 caracteres.

Es como el paciente y quien refiere reconocen el servicio, por ejemplo Consulta externa de cardiología.

Qué servicio se ofrece. Valores iniciales en el catálogo tipo de servicio de salud.

Regla de negocio: Obligatorio. Un servicio puede tener varios tipos (por ejemplo, un servicio de emergencias que también hace cirugía ambulatoria). La especialidad (cardiología, pediatría) no va aquí sino en especialidad.

Regla de validación: Debe pertenecer al catálogo tipo de servicio de salud. Si ningún concepto corresponde, se registra con su texto (binding extensible).

Comentarios: El catálogo es multisectorial: describe la función del servicio, no la forma en que una institución organiza sus servicios, y aplica igual a la CCSS, al INS, a los establecimientos privados y a otros prestadores como la Cruz Roja (pregunta 1).

Permite buscar qué servicios hay y dónde, con un catálogo común a los sectores público y privado (decisión 1). Es lo que consulta un sistema para saber a dónde referir.

Especialidades del servicio (por ejemplo, cardiología en una consulta especializada).

Regla de negocio: Obligatoria si el tipo de servicio es consulta-especializada; opcional en los demás.

Regla de validación: Debe pertenecer al catálogo especialidad en salud. Invariante cr-servicio-especialidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'consulta-especializada').exists() implies specialty.exists().

Comentarios: El catálogo está pendiente de los colegios profesionales (pregunta 4 del profesional de salud).

Permite encontrar una consulta de una especialidad concreta, por ejemplo cardiología, sin que el catálogo de tipos de servicio tenga que repetir cada especialidad.

Modalidades de imagen que ofrece un servicio de imágenes médicas. Ejemplos: tomografía computarizada (CT), resonancia magnética (MR), ultrasonido (US), mamografía (MG), radiografía digital (DX), radiografía computarizada (CR), medicina nuclear (NM), tomografía por emisión de positrones (PT), angiografía (XA), fluoroscopía (RF).

Regla de negocio: Solo se registra si el tipo de servicio es imagenes-medicas, y en ese caso es obligatoria. Permite buscar dónde hay un equipo determinado, por ejemplo dónde hay resonancia magnética.

Regla de validación: Debe pertenecer al ValueSet DICOM de modalidades (CID 33). Invariante cr-servicio-modalidad: type.coding.where(system = 'https://hl7.or.cr/fhir/terminology/CodeSystem/cr-tipo-servicio-salud' and code = 'imagenes-medicas').exists() = characteristic.coding.where(system = 'http://dicom.nema.org/resources/ontology/DCM').exists().

Comentarios: Es el mismo código de modalidad que llevará el estudio en la IG de informes de imágenes médicas (ImagingStudy.modality). DICOM es de uso libre, sin licencia.

Permite buscar dónde hay un equipo determinado, por ejemplo una resonancia magnética, con los códigos DICOM que ya usan los equipos y los sistemas de imágenes.

Qué necesita el paciente para usar el servicio. Valores: 1. Referencia de otro servicio o nivel de atención (referencia) 2. Orden de un profesional (orden-medica) 3. Cobertura o derecho a la atención (cobertura): seguro de salud de la CCSS, póliza del INS o de una aseguradora privada, o plan de la organización

Regla de negocio: Opcional: sin requisitos, el servicio es de acceso directo (por ejemplo, emergencias o vacunación). Por ejemplo, en la red de la CCSS las consultas especializadas suelen requerir referencia y cobertura (el seguro de salud); un hospital privado puede requerir cobertura de una póliza determinada, y los servicios de apoyo diagnóstico, en cualquier sector, orden-medica. Qué cobertura se acepta se detalla en eligibility.comment (por ejemplo, "Seguro de salud de la CCSS" o "Pólizas de gastos médicos del INS").

Regla de validación: Debe pertenecer al catálogo requisito de acceso. Un requisito que no esté en la lista (por ejemplo, una edad mínima) se registra con su texto en eligibility.code.text y el detalle en eligibility.comment (binding extensible).

Comentarios: No sustituye la verificación del derecho a la atención en cada caso, que se hará con el modelo de cobertura (pregunta 12 del paciente).

Dice qué necesita el paciente para usar el servicio (referencia, orden médica, cobertura), para que quien refiere lo prepare antes y el paciente no llegue sin él.

Indica si el servicio se atiende solo con cita previa.

Regla de negocio: Opcional. Si no se registra, no se sabe; no se supone que no requiere cita.

Evita que el paciente se presente sin cita en un servicio que solo atiende con cita previa.

Idiomas en que se puede atender en el servicio, además del español.

Regla de negocio: Opcional. Útil para el turismo médico y para las poblaciones indígenas.

Regla de validación: Código BCP 47.

Permite encontrar un servicio que atienda en otro idioma, para el turismo médico y las poblaciones indígenas.

Días y horas en que se ofrece el servicio. Cada ocurrencia es un bloque de días con el mismo horario.

Regla de negocio: Opcional. Un servicio con horarios distintos según el día lleva varias ocurrencias (por ejemplo, lunes a viernes de 7:00 a 16:00 y sábados de 7:00 a 12:00). Un servicio de 24 horas lleva todos los días con todoElDia. Las horas son de Costa Rica (UTC−6, sin horario de verano).

Regla de validación: Cada bloque se registra con todoElDia o con horaInicio y horaFin, no las dos cosas, y la hora de inicio es anterior a la de fin. Invariante cr-servicio-horario sobre availableTime.

Comentarios: Es el primer modelo que incluye horario: la ubicación y el rol del profesional lo dejaron fuera hasta que un caso de uso lo necesitara, y el directorio de servicios lo necesita (pregunta 4).

Dice cuándo se puede usar el servicio. El directorio de servicios lo necesita para referir o enviar al paciente en un horario en que lo atiendan (decisión 4).

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Días de la semana del bloque. Valores: mon, tue, wed, thu, fri, sat, sun.

Regla de validación: Debe pertenecer al ValueSet HL7 days-of-week.

Indica a qué días de la semana aplica el bloque de horario.

Indica que el servicio atiende las 24 horas en esos días.

Regla de validación: Ver la regla del horario.

Distingue un servicio de 24 horas, como emergencias, sin tener que dar las horas de inicio y fin.

Hora en que empieza la atención, en hora de Costa Rica.

Regla de validación: Formato hh:mm:ss, anterior a la hora de fin (invariante cr-servicio-horario).

Marca desde qué hora se atiende en esos días.

Hora en que termina la atención, en hora de Costa Rica.

Regla de negocio: Un horario que pasa la medianoche (por ejemplo, de 22:00 a 6:00) se registra como dos bloques.

Regla de validación: Formato hh:mm:ss, posterior a la hora de inicio (invariante cr-servicio-horario).

Marca hasta qué hora se atiende en esos días.

Teléfono del servicio (por ejemplo, para solicitar citas).

Regla de negocio: Opcional. Si no se registra, se usa el de la ubicación o el de la organización.

Regla de validación: Igual que en el paciente; la extensión interna va después de ;ext= (RFC 3966).

Permite al paciente o a quien refiere pedir una cita o hacer una consulta directamente al servicio.

Correo del servicio.

Regla de negocio: Opcional.

Regla de validación: Igual que en el paciente.

Sirve para las comunicaciones formales con el servicio.

Información adicional para el paciente o para quien refiere: preparación previa, avisos temporales, detalles del servicio.

Regla de negocio: Por ejemplo, Presentarse en ayunas de 8 horas o Resonador en mantenimiento hasta el 15 de octubre.

Regla de validación: Longitud máxima de 1000 caracteres.

Avisa de lo que el paciente o quien refiere debe saber y no cabe en otro dato: una preparación previa o un cierre temporal.