La versión 2.x no está basada explícitamente en un modelo de información subyacente. En consecuencia, no existen para esa versión test de compatibilidad HL7. La comunidad HL7 ha aceptado esa desventaja a favor de la mayor flexibilidad que ofrece el estándar. Los proveedores de software y sus sistemas son diversos, evolucionan lentamente, por lo tanto los beneficios de una gran prolijidad metódica deben ser pragmáticamente evaluados.

La arquitectura del protocolo HL7 implica un modelo de datos que se plasma en la estructura del mensaje. HL7 hace un intento razonable para asegurar que los diversos elementos de datos no se superpongan en las definiciones de los segmentos, por lo tanto la organización de los datos en los segmentos es análoga a un set de tablas de una base de datos relacional (análogo porque algunos mensajes abstractos pueden violar la norma básica de normalización de datos). Las definiciones de mensajes serían análogas a vistas a una base de datos que involucra múltiples tablas relacionadas para dar respuesta a las reglas del negocio.

Sin embargo ni el modelo de datos ni las reglas de negocio implícitas deben ser consideradas un reflejo genérico de todas las aplicaciones del área de salud. Si así lo hacen, es porque representan en gran medida lo que es aceptado comúnmente. En consecuencia, el desarrollo de interfaces HL7 es un esfuerzo de colaboración entre los usuarios y los técnicos responsables del desarrollo.

HL7 no recomienda vocabularios específicos, sino que define cuáles set de códigos son incluidos en el estándar. En la práctica esto resulta muy versátil y muchas implementaciones privilegian los vocabularios locales en lugar de los internacionales. Estos factores deben ser tenidos en cuenta por desarrolladores e implementadores. Actualmente se están considerando cambios respecto al uso de los vocabularios, que serán efectivos a partir de la versión 3 del estándar.