Liberada en enero 2011 presenta una revisión generalizada del estándar, aumentando la convergencia hacia la versión 3.
La lista de cambios más significativa con respecto a la versión 2.6 se describen a continuación:
Nota: una lista exhaustiva de los cambios puede encontrarse en el siguiente artículo: http://www.ringholm.com/docs/00750_en_HL7_27_features.htm
Tamaño de los campos
El concepto de “tamaño” siempre ha generado dudas a la hora de saber si una especificación es conforme.
Para aclarar la situación, la especificación define dos nuevos campos a añadir en la definición estática de campos, componentes y tipos de datos.
Normative Length (LEN): Se puede fijar únicamente para los tipos de datos “primitivos” (ID, DT, DTM, ST, IS, NM) y permite expresar los tamaños mínimos y máximos a respetar por aplicaciones conformes a la norma. Puede ser un rango inclusivo (Ej: 1..3), exclusivo (Ej: (1..3)) o una lista de posibles valores (Ej: 1,2,3).
Conformance Length: (C.LEN) Permite especificar la longitud mínima del dato que deben almacenar las aplicaciones receptoras para considerarse conformes a la norma. Este valor no se especifica en el estándar, sino que deben definir las guías de implementación. Como añadido, una guía de implementación nunca podrá fijar como valor máximo una cantidad menor que este valor. Se expresa como un número que puede estar seguido de un “=” o un “#”. El “=” implica que el dato no podrá ser nunca truncado, mientras que el “#” denota que es válido usar el mecanismo de trucado que también es novedad en esta versión. El “conformance profile” incorpora un apartado para este punto.
La norma define además un Mecanismo de trucando, herencia de ISO 22220 e 2752. Este mecanismo utiliza un nuevo carácter especial: el carácter de truncado (que por defecto es la almohadilla “#”) y que permite indicar a una aplicación que ha tenido que truncar un dato para poder almacenarlo en su modelo de persistencia.
Por ejemplo, si un HIS maneja tamaños de apellidos mayores que una aplicación departamental, cuando se informe de un paciente con una apellido que supere estos campos, el sistema departamental deberá indicar que está enviando el valor del apellido truncado para evitar que una regla de comparación rechace el resultado. Así por ejemplo enviará “APELLIDOMUYLARGO#”, siendo el último carácter el indicador de truncado.
Este carácter puede cambiarse, al igual que el resto de caracteres de control (|, ^, &, ~) y para ello el campo MSH-2 contiene ahora 4 caracteres, siendo el cuarto el “truncation character”.
Añadido “RE” como opcionalidad en las definiciones estáticas
El valor “RE” (Requerido si existe) hasta ahora era sólo utilizable en las guías de integración, sin embargo la versión 2.7 comienza a usarlos en la definición estática de campos, componentes y subcomponentes.
Endurecimiento de restricciones relativas a metadatos
En la versión 2.7 muchos elementos asociados a metadatos han pasado a ser obligatorios (R,RE) o a condicionales (C).
Nueva evolucíon datos codificados
El dato codificado simple (CE) desapareció en la versión 2.6 sustituido por los CWE y CNE. La versión 2.7 elimina el tipo “IS” por el CWE.
Los datos CWE y CNE se han extendido con varios elementos (pasan de 9 componentes a 22) que permiten indicar el OID, de los sistemas de codificación usados, así como la posibilidad de usar un código alternativo. También permite indicar si el código usado pertenece a un Value Set específico
El tipo de dato CX amplía dos nuevos datos para permitir indicar la versión del catálogo usado.
Cambios en la tabla 0200 “Name Type”
Es tabla es usada sobre todo en los tipos de datos asociados a nombres: PPN, XCN, XPN. Los cambios permiten alinearla más con las usadas en la V3.
Ampliación de cobertura de dominios Gestión de pacientes (capítulo 3)
Se define una nueva consulta: Find Candidates including Visit Information (Event QBP^Q32) Que permite consultar y recuperar datos en función del episodio.
El estándar incluye el concepto de “Service Episode”, que permite agrupar distinta actividad bajo un identificador trasversal (por ejemplo, permitiendo seguir un problema complejo como los oncológicos).
Se ha normalizado el uso de los números de teléfono en los segmentos PID y NK1: se han marcado como obsoletos los campos existentes (uno para el del trabajo, para casa, etc.) añadiendo un nuevo campo repetible de tipo XTN, que permite indicar el tipo de dato. Esto afecta a los segmentos PID y NK1.
Órdenes y resultados (capítulos 4 y 7)
El contenido de los mensajes de farmacia y vacunación se ha movido a un capítulo aparte: 4A -debido a su gran extensión-.
Se ha reorganizado la forma de informar de los actores que participan en los resultados: Todos Los campos que indicaban informantes se han marcado como obsoletos, y se ha creado un nuevo segmento: Participation Information (PRT) para expresar esta información. Esto afecta a campos tan consolidados como: OBR-10 Collector Identifier, OBR-16 Ordering Provider, OBR-28 Result Copies To, OBR-32 Principal Result Interpreter, OBR-34 Technician, OBR-33 Assistant Result Interpreter, OBR-34 Technician , OBR-35 Transcriptionist , OBX-15 Producer’s ID , OBX-16 Responsible Observer , OBX-18 Equipment Instance Identifier ,OBX-23 Performing Organization Name, OBX-24 Performing Organization Address, OBX-25 Performing Organization Medical Director.
La forma de relacionar un resultado con otro “padre”, ha cambiado: los campos ORC-31 y OBR-50 (ambos indicaban el parent universal service identifier) se han marcado como obsoletos y se han creado dos nuevos campos en el segmento OBR: OBR-51 (Observation Group ID) y OBR-52 (Parent Observation Group ID).
Esto es parte de una relación para fijar la relación entre el “id de orden (OBR-2) y el “tipo de prueba (OBR-4)” a “1:1”
Se ha añadido también un campo para un identificador alternativo a la orden: OBR-53 Alternate Placer Order Number.
La gestión de muestras se ha ampliado: Se han añadido dos pares de mensajes orientados al envío de muestras: Specimen shipment centric laboratory order (OML^O39) y laboratory order response (ORL^O40), y se han ampliado los campo para permitir una mejor identificación. Además se han creado segmentos nuevos centrados en la gestión del envío de muestras: SHP (Shipment), PAC (Shipping Package).
Intercambio de documentos clínicos (capítulo 9)
Se ha añadido el concepto de “carpetas” (folders) derivado de XDS, a través de añadir campos específicos al segmento TXA.
Gestión de citas (capítulo 10)
Se ha añadido un nuevo mensaje: notification of scheduled appointments message (SIU^S27) que permite cubrir escenarios de envío de recordatorios de citas.
Derivación de pacientes (capítulo 11)
Se ha añadido un juego completo de mensajes: “Collaborative Care Message (CCM)” que permiten cubrir más completamente el escenario de derivación.