Confluence de Health Level 7 (HL7) International

Bienvenido al espacio de trabajo de la comunidad HL7 para crear estándares de datos de salud que impulsen la interoperabilidad global.

Aquí en Confluence encontrará la documentación de cómo creamos estándares HL7, los registros y notas de toma de decisiones de todos nuestros subgrupos y una gran cantidad de recursos sobre la comunidad HL7, sus procesos y eventos. 

Este sitio es un espacio comunitario. Por favor, mantén tus modales. Agradecemos tu ayuda para mantenerlo actualizado y dinámico, con tus ediciones, comentarios y preguntas.

Un excelente punto de partida para tu aventura en HL7 es la página de Fundamentos de HL7 . También encontrarás consejos y documentación para usar Confluence y Jira en tu trabajo con HL7 . Si eres nuevo aquí, deberás solicitar una cuenta gratuita antes de participar.

Contenido

Health Level Seven International (HL7)

Health Level Seven International (HL7) es una organización de desarrollo de estándares sin fines de lucro acreditada por ANSI, dedicada a proporcionar un marco integral y estándares relacionados para el intercambio, la integración, la distribución y la recuperación de información de salud electrónica que respalda la práctica clínica y la gestión, prestación y evaluación de servicios de salud.

HL7 cuenta con el respaldo de más de 1.600 miembros de más de 50 países, incluidos más de 500 miembros corporativos que representan a proveedores de atención médica, partes interesadas gubernamentales, pagadores, compañías farmacéuticas, proveedores y empresas de consultoría.

Comités y consejos de HL7

Grupos de gestión de productos y servicios HL7

Programas aceleradores HL7 FHIR

Grupos de trabajo de HL7

Afiliados de HL7 a Confluence

Otras colaboraciones e iniciativas

Recursos clave

Política de uso aceptable de HL7

Creado por David Johnson

Introducción

El sitio web de HL7 Confluence es un sitio editado por la comunidad de Health Level Seven International. Esta Política de Uso Aceptable (PUA) se aplica a todos los sitios de Confluence de la marca HL7 y tiene como objetivo ayudar a todos los usuarios de HL7 Confluence y JIRA (registrados o no) a comprender cómo se puede utilizar el sitio de HL7 Confluence. Todos los usuarios del sitio de HL7 Confluence deben cumplir con esta PUA, cuyo objetivo es fomentar la reutilización de los materiales de HL7, preservando la propiedad intelectual (PI) de HL7 y protegiendo a los miembros y participantes de la comunidad de HL7 de actividades ilegales o irresponsables.

El sitio de HL7 Confluence y JIRA está cubierto por los Términos y Condiciones de Uso de HL7 disponibles en el sitio web hl7.org :  http://www.hl7.org/legal/tc.cfm . Esta PUA debe leerse junto con dicho documento. Si bien el material del sitio de HL7 Confluence y JIRA está disponible al público, no se considera  contenido abierto . Puede contener propiedad intelectual protegida según lo estipulado en los  Estatutos de HL7  y su  Manual de Gobierno y Operaciones (GOM) , o puede representar material en desarrollo para estándares que estará sujeto a derechos de autor una vez que se logre el consenso en la comunidad de HL7.

Si bien no se permite la edición anónima, permitimos que cualquier persona se registre. Una vez que un usuario obtiene acceso, no se realiza un seguimiento activo de su actividad (puede añadir lo que desee). Además, el contenido enviado al sitio de HL7 Confluence y JIRA no está sujeto a la  Política de Privacidad de HL7 . El contenido del sitio de HL7 Confluence y JIRA es escrito y mantenido de forma colaborativa por voluntarios.

Objetivo

El sitio de HL7 Confluence y JIRA es un recurso gratuito y abierto diseñado principalmente para la colaboración entre los miembros de HL7 con el fin de gestionar las actividades de desarrollo. HL7 se basa en la colaboración de sus participantes, miembros de la comunidad, miembros registrados y usuarios. Con este fin, HL7 permite el acceso a su sitio y a los materiales que contiene para uso personal y no comercial, según lo establecido en esta política. HL7 se compromete a crear los mejores y más utilizados estándares en el ámbito de la salud, ampliando el acceso al desarrollo de estándares de alta calidad que puedan incorporarse fácilmente a las iniciativas de integración.

HL7 no se responsabiliza de las opiniones de sus miembros, ni de sus errores u omisiones, ni de las consecuencias derivadas del uso de la información aquí contenida. Este Sitio puede contener contenido de terceros (p. ej., artículos, fuentes de datos, resúmenes, logotipos, etc.) y también puede incluir hipervínculos a sitios web de terceros. Proporcionamos dicho contenido y enlaces de terceros como cortesía a nuestros usuarios y no respaldamos, patrocinamos, recomendamos ni asumimos ninguna responsabilidad por dichos sitios web o contenido de terceros, ni por su disponibilidad.

Acuerdo

Al utilizar el sitio de HL7 Confluence y JIRA, usted acepta cumplir con los términos de esta Política de Uso Aceptable (PUA) y se compromete a utilizar cualquier contenido del sitio, ya sea total o parcialmente, únicamente con fines no comerciales y educativos. Asimismo, acepta cumplir con la legislación vigente de Estados Unidos en materia de derechos de autor y la Ley de Derechos de Autor del Milenio Digital de 1998.

Pautas

  • No utilice el sitio de HL7 Confluence y JIRA para anunciar, publicitar ni promocionar empresas, proveedores o personas, ni sus productos, servicios, ofertas o eventos específicos. Queda expresamente prohibido el uso del sitio de HL7 Confluence y JIRA para beneficio personal.
  • No distribuya ni publique información privada o personal de otro miembro del foro sin su permiso expreso. Esto incluye nombres, direcciones, números de teléfono y otra información relevante. No recopile direcciones de correo electrónico, nombres de usuario ni otros identificadores ni información personal sin el consentimiento de la persona identificada (incluyendo, entre otros, phishing, estafas por internet, robo de contraseñas, rastreo web y recolección de datos). No recopile ni utilice información sin el consentimiento de la fuente de la información.
  • No publique material que sea deliberadamente falso, engañoso o inexacto. El vandalismo constituye una infracción grave.
  • No publiques contenido, incluidos comentarios, que no esté relacionado con el tema de la página. Al publicar información de segunda mano, indícalo como tal.
  • No cargue, publique, envíe por correo electrónico, transmita ni ponga a disposición de otro modo ningún contenido que no tenga derecho a poner a disposición.
  • No publique contenido que involucre ataques personales, o que sea excesivamente violento, incite a otros a la violencia, amenace con ejercer violencia sobre otra(s) persona(s) o que contenga contenido que sea deshonroso o que contenga lenguaje acosador o de odio.
  • No publique contenido que no sea apto para niños. Cualquier comentario deliberadamente falso o realizado con total desprecio por la verdad podría ser utilizado en su contra en un tribunal. Nunca puede saber con certeza cómo reaccionará el destinatario de sus comentarios. Sus comentarios son personales y no reflejan en modo alguno la opinión de otros ni el consenso de la comunidad de HL7. Por el contrario, asuma que no está siendo atacado.
  • No retome asuntos ya planteados, debatidos y decididos. Reanude una discusión solo si tiene información nueva significativa que justifique una reconsideración de la decisión original.
  • No edites los comentarios de otros usuarios sin su permiso, excepto para añadir enlaces que mejoren la interconexión del sitio. No elimines los comentarios de otros usuarios a menos que sean irrelevantes para la página en la que se encuentran o infrinjan las normas de etiqueta de HL7. Si eliminas el comentario de otro usuario, prepárate para justificarlo si no está de acuerdo con tu eliminación.
  • No suplante a ninguna persona o entidad, ni falsifique o manipule identificadores para ocultar el origen de cualquier publicación.
  • No reproduzca, duplique, copie, venda, comercie, revenda ni explote con ningún propósito comercial ninguna parte del sitio de Confluence y JIRA, el uso del sitio de Confluence y JIRA o el acceso al sitio de Confluence y JIRA.

Violaciones

Todos los miembros de la comunidad deben tomar medidas para denunciar a los usuarios y publicaciones que infrinjan esta Política de Uso Aceptable (PUA). Las infracciones pueden reportarse a los administradores a través del  Webmaster . Las infracciones de la PUA pueden resultar en la eliminación del sitio de Confluence y JIRA, así como de otros recursos de HL7. En caso de infracciones menores, recomendamos una solicitud discreta en la página del usuario infractor antes de iniciar procedimientos administrativos. Reacciones de HL7 a las infracciones:

  • 1ª infracción: Advertencia por escrito a la dirección de correo electrónico del infractor.
  • 2da infracción: Advertencia escrita publicada en la página del autor de la infracción y suspensión y/o terminación del acceso al sitio HL7 Confluence y JIRA.
  • 3.ª infracción: La suspensión y/o terminación del acceso a todos los recursos y características de HL7, incluida la opción de notificar a la institución de origen del infractor sobre el abuso de los servicios o características de HL7 y/o otras acciones que HL7 considere apropiadas.

Participando en HL7

Creado por Lloyd McKenzie

Quienes somos

HL7 International se constituyó oficialmente como organismo de desarrollo de estándares bajo el Instituto Nacional Estadounidense de Estándares (ANSI). Si bien ANSI es una organización específica de EE. UU., muchas de las especificaciones que desarrolla HL7 están destinadas al consumo internacional. (En el lenguaje de HL7, se denominan especificaciones “universales” o “UV”). HL7 también cuenta con un gran número de afiliados internacionales que contribuyen al desarrollo de sus estándares, así como a su adaptación al entorno específico de cada país. EE. UU. es un caso especial y no cuenta con un afiliado independiente, sino con un grupo específico —el Comité Directivo del Dominio de EE. UU.— que ayuda a coordinar el desarrollo de estándares específicos para EE. UU.

Casi todo el trabajo que se realiza en HL7 lo realizan voluntarios, aunque muchos de ellos reciben financiación de sus empleadores para participar. La participación está abierta a cualquier persona y damos la bienvenida a una amplia gama de perspectivas: desarrolladores y proveedores de software, profesionales clínicos, pacientes y cuidadores, académicos, aseguradoras, gubernamentales, farmacéuticas, etc. Algunos participantes son consultores independientes que dedican gran parte de su tiempo a diversos proyectos de HL7. Además de su equipo de voluntarios, HL7 cuenta con un pequeño equipo que colabora en el mantenimiento de la infraestructura de la organización: gestiona los sitios web y otros servicios técnicos, organiza y gestiona reuniones, presta servicios administrativos a los órganos de gobierno, apoya la formación y la divulgación, etc.

Estructura de la organización

La organización HL7 se divide en aproximadamente 40 ” grupos de trabajo ” que abarcan diferentes áreas de la atención sanitaria, como farmacia, salud pública, investigación, etc. Algunos grupos de trabajo solo cuentan con un número reducido de participantes activos, mientras que otros pueden tener entre 40 y 50, además de muchos otros que contribuyen ocasionalmente. Cada grupo de trabajo también cuenta con entre 2 y 6 copresidentes elegidos por los participantes, quienes se encargan de presidir las reuniones, organizar las agendas y, en general, de garantizar que el trabajo dentro de cada grupo se lleve a cabo de forma fluida y eficiente.  Los diversos grupos de trabajo  reportan al Comité Directivo Técnico (TSC), que supervisa el desarrollo de estándares en toda la organización. Además, existen otros órganos de gobierno que gestionan algunas de las principales familias de productos para las que desarrollamos estándares y que brindan soporte específico para los procesos organizativos. Estos generalmente también reportan al TSC. Finalmente, la Junta Directiva de HL7 proporciona supervisión estratégica y gestiona la dirección estratégica y la estabilidad financiera de la organización.

Involucrarse

HL7 da la bienvenida y anima a los nuevos participantes a participar en los debates y contribuir al desarrollo de nuestras especificaciones. Animamos a todos los participantes a hacerse miembros, ya que contribuye a la organización y ofrece diversas ventajas  , como la reducción de costes en reuniones y formación. Ser miembro de HL7 o de una de sus filiales es un requisito para asumir un papel de liderazgo oficial, es decir, ser elegido copresidente, miembro de uno de los órganos de gobierno o de la junta directiva. La membresía también es necesaria para participar gratuitamente en la votación formal de las normas propuestas. Quienes no sean miembros, pero sí de otras organizaciones de normalización, pueden tener derecho a voto recíproco; sin embargo, deberán abonar una cuota por cada especificación sobre la que deseen votar.

Sin embargo, más allá de participar en la gobernanza o la votación formal, la contribución al desarrollo de estándares de HL7 está abierta a todos. Quienes no sean miembros pueden unirse a las llamadas, participar en  http://chat.fhir.org  (el foro de discusión de la comunidad de HL7), enviar solicitudes de cambio a las especificaciones de HL7 y votar en las decisiones de los grupos de trabajo. 

Para participar en un grupo de trabajo específico, visite su página en el sitio web de HL7 ( http://www.hl7.org/special/committees ) y suscríbase a su lista de correo o busque la próxima hora de la conferencia telefónica . También puede enviar un correo electrónico a los copresidentes y preguntarles cuál es el mejor mecanismo para participar.

Más información

Entendiendo el proceso de normalización

Creado por Lloyd McKenzie

Entendiendo el proceso de normalización

El proceso de normalización en HL7 (y en otras organizaciones de desarrollo de estándares) puede parecer complejo, burocrático y excesivamente lento. Sin duda, existen áreas del proceso que pueden y deben mejorarse. Las áreas que parecen ineficientes o que crean barreras innecesarias para realizar un trabajo útil pueden y deben ser cuestionadas.

Sin embargo, quienes se inician en el mundo de los estándares pueden tener ideas erróneas sobre qué es el proceso de estándares y qué puede/debe lograr. Esta página pretende explicar qué hacemos, por qué utilizamos algunos de nuestros procesos y cómo maximizar los beneficios del uso de HL7.

Obtenga más información sobre cómo participar en HL7:  Participar en HL7

¿Por qué crear un estándar?

Algunos se incorporan al proceso HL7 creyendo que el objetivo general es obtener la aprobación necesaria, tras lo cual la comunidad puede centrarse en lo importante: la implementación. Esta creencia es comprensible, dado que en ocasiones HL7 también lo ha pensado. Es decir, que la prioridad era publicar algún tipo de documento con la etiqueta adecuada.

Resulta que crear una especificación y etiquetarla no es tan difícil. Lo que realmente importa es lo que representa la etiqueta. La etiqueta solo es valiosa en la medida en que demuestra que la especificación refleja las cualidades que sus patrocinadores y consumidores esperan de ella. Un estándar solo es valioso en la medida en que se adopta y que dicha adopción logra los resultados que pretendía alcanzar.

Para cumplir el objetivo de adopción y alcanzar los resultados deseados, el proceso de normalización debe hacer cinco cosas:

  1. Fomentar el consenso,
  2. Asegúrese de que el contenido sea adecuado para su propósito.
  3. Asegúrese de que el contenido sea implementable.
  4. Establecer una comunidad de implementadores adecuada y
  5. Garantizar el mantenimiento continuo del estándar. 

Sin los cinco aspectos, la probabilidad de una amplia adopción se reduce significativamente.

Las capacidades de HL7 y su esfuerzo al patrocinar proyectos desempeñan un papel en el logro de estos objetivos, aunque los proyectos también deben ser conscientes de las limitaciones innatas del proceso de normalización .

Fomentar el consenso

La especificación debe cumplir los requisitos y reflejar el acuerdo de las distintas partes de la comunidad que participarán en el flujo de trabajo para el cual el estándar establece expectativas. Esto significa:

  • Garantizar que exista un límite claro en torno a qué partes del flujo de trabajo están cubiertas por el estándar
  • Identificar a las partes interesadas involucradas en las partes relevantes del flujo de trabajo 
  • Involucrar a las partes interesadas para que participen en el proceso de estandarización abierta (y mantenerlas comprometidas a medida que avanza el estándar)
  • Garantizar que los requisitos de cada grupo de interesados ​​se escuchen y registren de manera que los demás participantes puedan comprenderlos de forma coherente.
  • Priorizar y armonizar dichos requisitos de manera que haya un único conjunto integrado de requisitos con los que todas las partes interesadas puedan estar de acuerdo o al menos aceptar
  • Garantizar que la especificación resultante creada para cumplir esos requisitos refleje una solución con la que las partes interesadas también estén de acuerdo o puedan aceptar

Los procesos de la organización de desarrollo de normas deben respaldar de forma transparente todos estos aspectos y deben hacerlo durante todo el ciclo de desarrollo de normas.

El proceso de consenso es clave para garantizar resultados de dos maneras:

  1. Si los participantes no aceptan la especificación, es poco probable que la implementen. Incluso si existe una dinámica de poder regulatoria o similar, las partes interesadas que no consideran que sus necesidades o deseos se vean reflejados pueden, a menudo, obstaculizar o retrasar la implementación. Por otro lado, pueden implementarla de forma que cumpla con la letra técnica de la especificación sin alcanzar los objetivos deseados. Por otro lado, si una especificación cuenta con el apoyo de las partes interesadas, es más probable que la implementación se lleve a cabo, de manera oportuna y de forma alineada con los objetivos previstos.
  2. Para lograr los resultados deseados, la solución debe adaptarse al contexto de implementación. Una solución que no considera los procesos de negocio, los requisitos regulatorios, la capacidad u otras limitaciones o requisitos de uno o más grupos de interés a menudo simplemente no funcionará, independientemente del compromiso de las partes con la implementación. Una perspectiva amplia y participantes informados son esenciales para garantizar que todos los aspectos de los procesos y grupos de interés afectados se consideren en el proceso de diseño.

Un beneficio adicional del proceso de consenso es que a menudo se puede identificar un valor adicional como parte del proceso de diseño que da como resultado que una especificación logre más beneficios de los que se habían previsto originalmente y encuentre una audiencia más amplia que la que se había buscado originalmente.

Las comunidades más grandes brindan más apoyo a los implementadores y un mejor soporte continuo para la evolución del estándar.

Si bien los procesos del comité de HL7 funcionan técnicamente por mayoría de votos, la aceptación de una dirección propuesta sugiere que no existe consenso. Los grupos de trabajo se esforzarán por encontrar una solución con un porcentaje de votos a favor mucho mayor que el mero “50% + 1”. Al votar formalmente las especificaciones, se requieren porcentajes considerablemente mayores de votos favorables.

En HL7, al garantizar una representación adecuada de los puntos de vista, nos esforzamos especialmente por asegurar la representación adecuada de quienes realmente implementarán la especificación: quienes escribirán el código o, al menos, quienes decidirán si se escribirá o no. Fundamentalmente, estas partes interesadas son el público objetivo de la mayoría de las especificaciones que elaboramos. Por lo tanto, su acuerdo y su disposición a realizar los cambios de software necesarios para implementar la especificación en sus propios productos es fundamental para el éxito de la misma. Ejemplos de cómo HL7 contribuye a la generación de consenso:

  • Garantizar que todos los grupos de trabajo pertinentes tengan la oportunidad de copatrocinar o figurar como partes interesadas en la [Declaración del alcance del proyecto].
  • Anunciar proyectos propuestos a la ANSI y a las comunidades internacionales y, en algunos casos, a otras organizaciones de desarrollo de normas para alentar a las partes interesadas a participar.
  • Garantizar que todas las reuniones en las que se discuta la especificación propuesta y los connectathons que la prueben se anuncien abiertamente y estén abiertos a todos los participantes interesados.
  • Solicitar activamente una representación equilibrada de los diferentes grupos de interesados ​​al realizar la revisión de las votaciones.
  • Brindar oportunidades para recibir comentarios abiertos sobre las especificaciones a lo largo de su ciclo de vida.
  • Realizar “encuestas informales” para comprobar si hay consenso y ver si es necesario más debate o experimentación por parte de los implementadores antes de convocar votaciones formales.
  • Al votar sobre especificaciones normativas, garantizar que todos los votantes consideren los comentarios negativos no resueltos y consideren si desean cambiar su voto.

Garantizar la idoneidad para el propósito

La solución reflejada en la especificación debe funcionar según lo previsto. Esto significa:

  • Debe ser capaz de trabajar con los insumos que las partes interesadas pueden proporcionar.
  • Debe ser capaz de producir resultados que las partes interesadas puedan consumir.
  • Debe dar como resultado los objetivos que la norma pretende alcanzar.
  • Debe hacer lo anterior en las diversas circunstancias que afectan el funcionamiento diario de los sistemas de atención sanitaria pertinentes.
  • Debe gestionar los fallos/excepciones de una manera que sea segura para las partes interesadas afectadas.

La idoneidad para el propósito puede considerarse un factor booleano: algunas soluciones alcanzarán los resultados deseados, otras no. Sin embargo, en la práctica, se trata de un rango. Las soluciones pueden alcanzar los resultados deseados con mayor o menor frecuencia, en circunstancias más específicas o más amplias y con costos mayores o menores. La percepción de la idoneidad puede variar según el grupo de partes interesadas. Por lo tanto, la idoneidad suele ser una medida ponderada de la idoneidad para numerosos objetivos. El proceso de normalización intenta primero identificar soluciones candidatas y luego evaluarlas.

La amplitud de las soluciones evaluadas está determinada por la creatividad de quienes realizan el diseño, la amplitud y precisión de sus perspectivas y el tiempo que tienen disponible para idear y evaluar alternativas.

La aptitud física puede incluir consideraciones como:

  • ¿La especificación introducirá riesgos de seguridad?
  • ¿Creará problemas con las admisiones, la facturación u otros procesos comerciales críticos?
  • ¿Requiere capturar elementos de datos que a veces no están disponibles?

La idoneidad de las soluciones se evalúa mediante dos mecanismos principales:

  1. Evaluación de la especificación por parte de un conjunto suficientemente diverso y competente de partes interesadas frente a la gama potencial de entradas y salidas, así como evaluación de la claridad, el rigor y la precisión de la especificación.
  2. Prueba de la especificación en entornos de prueba y del mundo real para verificar el funcionamiento en situaciones complejas que no necesariamente se pueden predecir o intuir simplemente mediante la evaluación.

Ser implementable

Es posible que una solución que técnicamente cumple con los objetivos de la comunidad no sea implementable por uno o más de los grupos de interés involucrados. Para ser implementable, una especificación debe lograr lo siguiente:

  • Debe cumplir con las restricciones regulatorias, técnicas y de capacidad de los desarrolladores de software, proveedores y entornos de implementación que deben implementar parte o la totalidad de la especificación.
  • Debe definir la solución con suficiente precisión, rigor y claridad/comprensibilidad para que las partes interesadas puedan implementar la especificación de manera independiente y consistente y así lograr los resultados deseados.
  • Debe garantizar que el retorno de la inversión de los recursos (dinero, tiempo, experiencia) gastados para implementar la especificación sea lo suficientemente grande para cada parte interesada (particularmente cuando se compara con los beneficios para esa parte interesada) como para que tenga sentido comercial que todas las partes interesadas la implementen (y la implementen más temprano que tarde).

La implementabilidad incluye consideraciones como cumplir con los estándares subyacentes, trabajar dentro de las capacidades de las tecnologías de bases de datos y los lenguajes de desarrollo existentes, garantizar que las definiciones se expresen en términos comprensibles para los no expertos, etc.

Al igual que la idoneidad para el uso, la implementabilidad se desarrolla en un continuo y puede implicar concesiones entre los grupos de interés. Estas concesiones se dan como parte del proceso de consenso.

La garantía de implementabilidad se gestiona mediante los mismos dos mecanismos que la “idoneidad para el uso”: proporcionar una combinación de oportunidades adecuadas de revisión y prueba.

Establecer una comunidad de implementadores

Salvo en el caso de la regulación, la idea de “construirlo y vendrán” rara vez tiene éxito en el ámbito de los estándares. Muchas especificaciones se han desarrollado mediante procesos de consenso dentro de HL7 y otras organizaciones de estándares que eran implementables y aptas para su propósito, pero que tuvieron poca o ninguna adopción.

La adopción requiere concienciación y disposición de la comunidad de implementadores objetivo. Crear esta concienciación implica divulgación, conexión, educación, promoción y participación de las partes interesadas que (idealmente) implementarán o se verán afectadas por la especificación. Esto incluye la participación de un subconjunto de las partes interesadas en el proceso de desarrollo de estándares (para garantizar un consenso representativo). Sin embargo, también implica poner el estándar en el radar de quienes quizás no deseen participar en el desarrollo, pero que deberían planificar y presupuestar su futura adopción.

Además de asegurar un terreno fértil para el nuevo estándar, es fundamental construir una comunidad para brindar apoyo a las actividades de los implementadores. Ninguna especificación producida podrá abarcar todos los matices y casos extremos que se encontrarán en el ámbito de la implementación. Contar con una comunidad conectada de implementadores que puedan comunicarse y consensuar cómo gestionar estos problemas es esencial para garantizar una implementación consistente y la adaptación de la especificación a entornos reales.

Estas comunidades de implementación también proporcionan una rampa de acceso para aquellos nuevos en la especificación, crean herramientas y otros materiales que facilitan la implementación, brindan asesoramiento y educación a otros implementadores y ayudan a comprender la escala de la especificación desde el subconjunto inicial más pequeño de partes interesadas involucradas en el proceso de desarrollo hasta el conjunto mucho más grande de partes interesadas que necesitan adoptarla para lograr los resultados deseados.

En algunos casos, la comunidad implementadora ya existe (constituida a través de otras normas, promoción u otras actividades). En estos casos, el objetivo es integrar la comunidad de desarrollo de normas en la comunidad de implementación existente para que el conocimiento fluya en ambas direcciones y la retroalimentación se integre en el proceso de desarrollo de normas. En otros casos, la comunidad debe formarse o expandirse para alcanzar la amplitud y profundidad de implementación deseadas, y para alcanzar los objetivos de la especificación.

Ya sea que se trate de formar, hacer crecer o integrar la comunidad, los mecanismos son los mismos: participación a través de la difusión, la defensa, la conexión y la educación.

La formación de la comunidad de implementación comienza con los mismos procesos que los utilizados para formar el grupo de consenso, pero agrega numerosos otros aspectos:

  • Proporcionando educación y seminarios web, artículos en boletines.
  • Patrocinando connectathons en reuniones de grupos de trabajo, DevDays y varios otros foros
  • Listas de servidores de alojamiento, transmisiones de Zulip e interacción con implementadores por otros medios como Stack Overflow

Mantenimiento continuo

Para tener éxito, un estándar debe ser dinámico. Debe actualizarse a medida que surjan problemas, se requieran aclaraciones, evolucionen los requisitos y cambie el entorno técnico. Esto requiere lo siguiente:

  • Una representación significativa de la comunidad que desarrolló originalmente el estándar debe permanecer de alguna forma, incluso después de que se complete el proyecto inicial (y se gasten sus recursos asociados).
  • En la medida de lo posible, se debe conservar el conocimiento de la comunidad a medida que sus miembros van y vienen.
  • La especificación en sí debería haber sido diseñada para permitir una evolución futura, como la expansión del uso a nuevos proveedores o comunidades geográficas, la provisión de mecanismos para mejorar o ajustar el comportamiento en futuras versiones y el establecimiento de prácticas para las implementaciones para gestionar la probable situación en la que múltiples “versiones” de la especificación se utilicen simultáneamente.

Todas las consideraciones involucradas en la especificación original —la formación de consenso, la verificación de la idoneidad para el propósito y la implementabilidad, y el fomento y la retención de una comunidad— son relevantes en el proceso de mantenimiento. Mientras una especificación sea relevante, habrá un proceso iterativo continuo de revisión y adopción, aunque la intensidad de dicho proceso aumentará o disminuirá según la estabilidad del espacio de implementación.

HL7 garantiza que todo el contenido se gestione mediante el control de código fuente y está migrando a un mecanismo de seguimiento basado en Jira para todas las especificaciones que han superado el estado de “borrador”. La documentación de Confluence, incluidas las actas de reuniones y los puntos de decisión, también ayuda a conservar el conocimiento institucional. Y lo más importante, HL7 se esfuerza por seguir produciendo contenido nuevo, relevante e interesante. Esto motiva a los participantes a mantenerse involucrados y, por lo tanto, a estar disponibles para apoyar el mantenimiento de las especificaciones publicadas previamente.

Consideraciones adicionales

Existe un equilibrio entre el tiempo y la energía invertidos y el grado en que se pueden lograr estos “beneficios” del proceso de normalización. Si se dedica muy poco tiempo y energía, es improbable que la norma sea adecuada para su propósito o tenga una amplia adopción. Si se demora demasiado o requiere demasiada inversión, la comunidad la abandonará antes de que la especificación se declare “apta para su uso”.

Dentro del proceso de normalización de HL7, normalmente transcurren de uno a dos años desde su inicio hasta que una especificación está disponible como “Estándar para Prueba”, y más de tres años después hasta que el contenido se ha utilizado lo suficiente como para consolidarse como “normativo” (es decir, un estándar ANSI relativamente estable que busca mantener la retrocompatibilidad a medida que se crean nuevas versiones). Este último plazo depende principalmente de la rapidez con la que la comunidad de implementadores puede adoptar una versión de una especificación en producción, proporcionar retroalimentación al proceso de normalización y, posteriormente, avanzar hacia la versión revisada resultante.

Lo que HL7 aporta al proceso de normalización

HL7 lleva más de 30 años desarrollando estándares de atención médica. Ha aprendido (y sigue aprendiendo) mucho sobre cómo realizar todas las funciones mencionadas.

  • Cuenta con procesos establecidos para ayudar a formar comunidades, realizar revisiones, fomentar las pruebas y realizar una revisión equilibrada y objetiva de las especificaciones.
  • Tiene una gran comunidad que, en conjunto, tiene una experiencia extremadamente profunda en prácticamente todas las áreas de la atención médica y las tecnologías relevantes para el intercambio de datos.
  • Lo que es más importante, cuenta con una comunidad apasionada y entusiasta por utilizar la tecnología para mejorar el flujo de información en la atención sanitaria y, de ese modo, mejorar la vida de las personas en todo el mundo.

Las capacidades específicas incluyen:

  • Procesos al inicio de los proyectos para garantizar que el alcance esté bien definido, que el conocimiento del trabajo previsto se propague tanto en nuestra organización como a la comunidad externa, que se aproveche la experiencia relevante dentro de la organización y que exista coordinación para minimizar la probabilidad de que se produzcan especificaciones superpuestas o conflictivas.
  • Procesos para ayudar a garantizar una representación equilibrada y la transparencia en el desarrollo, la revisión y el cambio de especificaciones.
  • Infraestructura técnica para apoyar la formación de comunidades, la comunicación y la retención/intercambio de conocimientos (Confluence, Github, Zulip, conferencias telefónicas, reuniones de grupos de trabajo, etc.)
  • Metodologías formales (y procesos para mantener esas metodologías) para guiar la creación de especificaciones de calidad consistentes y de buena calidad basadas en nuestros estándares fundamentales
  • Maratones de conexión regulares, registros compartidos y entornos de prueba para respaldar la validación continua de las especificaciones a medida que se desarrollan
  • Mecanismos para solicitar la revisión de un amplio grupo de expertos con conocimientos y procesos para coordinar las respuestas a la retroalimentación proporcionada (y la adaptación de las especificaciones resultantes).
  • Infraestructura para apoyar el desarrollo, publicación, distribución y gestión continua de versiones de especificaciones
  • Procesos de gestión para coordinar el trabajo de nuestros numerosos comités y facilitar procesos comunitarios como votaciones y publicaciones
  • Procesos de gobernanza para garantizar que todas las partes interesadas tengan la oportunidad de ser escuchadas y que las especificaciones se desarrollen de manera colaborativa y consensuada.
  • Afiliadas regionales en numerosos países, asociaciones con otras organizaciones relacionadas con las normas, gobiernos y partes interesadas clave y alcance de marketing para crear conciencia sobre las especificaciones producidas.

¿Qué se espera que los proyectos aporten al proceso?

Si bien HL7 cuenta con una amplia experiencia en diversas áreas y un amplio alcance en su comunidad, está compuesta casi exclusivamente por voluntarios. Algunos son verdaderos voluntarios y apoyan el desarrollo de estándares en su tiempo libre. Otros reciben el apoyo de sus empleadores o clientes. En ambos casos, su capacidad es limitada.

Se espera que los proyectos que buscan impulsar la transformación de la atención médica mediante el desarrollo de estándares aporten recursos que faciliten el trabajo. Esto podría implicar la incorporación de personas remuneradas o voluntarias que colaboren con el desarrollo de contenido, la coordinación de revisiones, la gestión o participación en maratones de conexión, etc. En otros casos, podría implicar la financiación de quienes ya forman parte de la comunidad para que puedan dedicarse más a la labor que requiere el proyecto.

En cualquier caso, los proyectos deben reconocer que se están integrando en una comunidad. Esta dedicará su tiempo y energía a impulsar el progreso del proyecto. Sin embargo, la comunidad está compuesta por otros que también buscan impulsar sus propias iniciativas de normalización. Los promotores de proyectos deberán respetar la necesidad de HL7 de apoyar múltiples proyectos, compartir recursos comunes (tiempo del comité, revisores, etc.) y también esperar contribuir al progreso de otras iniciativas de normalización no directamente relacionadas con los objetivos de su propio proyecto.

Los proyectos deberán reclutar expertos de sus respectivas comunidades para que participen en HL7. Si bien contamos con una amplia experiencia, es poco probable que contemos con representantes de todos los grupos de interés que se verán afectados por la especificación propuesta (y los representantes que tengamos no siempre tendrán la capacidad para brindar el apoyo necesario). También esperamos que los participantes del proyecto animen a sus organizaciones a unirse como miembros de HL7 para apoyar la organización y la infraestructura de HL7.

HL7 cuenta con procesos que garantizan que las especificaciones alcancen sus objetivos de adopción y los resultados deseados. Si bien las necesidades de los proyectos varían, la consistencia relativa de los procesos y la gobernanza es esencial para el buen funcionamiento de la comunidad. Si bien en algunos casos se pueden conceder excepciones a las expectativas de HL7, estas serán excepcionales y se evaluarán en función del objetivo general del proceso o la norma que se exime o se ajuste. En definitiva, la credibilidad y la marca de HL7 se verán afectadas por la calidad de lo producido, y HL7 se reserva el derecho de garantizar que se sigan los procesos que contribuyan a garantizar dicha calidad, incluso si ello implica concesiones o un proceso más largo de lo deseable.

Se alienta a los proyectos a contribuir a los recursos comunitarios a través del apoyo a herramientas, educación, trabajo de código abierto, etc., que beneficiarán no solo su propio trabajo, sino a toda la comunidad de estándares.

Como se mencionó anteriormente, un componente esencial del proceso de normalización es el mantenimiento continuo. Si bien los proyectos pueden contar con financiación y recursos limitados en el tiempo, deben planificar cómo se mantendrá la especificación inicial una vez finalizado el proyecto. Idealmente, esto debería incluir a las personas que colaboran voluntariamente con la comunidad mucho después de la finalización del proyecto, así como el apoyo continuo de la organización a HL7. Como mínimo, debe garantizar que los productos del trabajo estén bien documentados e incluyan todo el material fuente, los registros de la toma de decisiones y su justificación, y que exista una transferencia de conocimientos entre los participantes del proyecto y los miembros de la comunidad de HL7 que brindarán apoyo una vez finalizado el proyecto.

Se espera que todos los participantes del proyecto actúen con ética y de acuerdo con las normas y directrices de HL7. Esto incluye revelar posibles conflictos de intereses, ayudar a evitar la preponderancia real o percibida de influencia, cumplir las normas sobre el uso de la propiedad intelectual y, en general, no intentar anteponer sus intereses personales al bien de la comunidad.

Las limitaciones del proceso de normalización

Por mucho que quisiéramos lo contrario, los estándares no son mágicos.

  1. Tanto la comunidad de estándares como la de implementadores tienen un margen de maniobra limitado. HL7 hará todo lo posible por ser justo con todos los proyectos, pero la priorización se realizará cuando los recursos sean limitados. Independientemente de la importancia de los objetivos de un proyecto, la regulación pendiente (o activa), los plazos de financiación u otras consideraciones, no siempre será posible cumplir los plazos deseados ni obtener la participación deseada. Además, el proceso de HL7 debe incluir hitos y expectativas específicos que todos los proyectos deben cumplir para garantizar la equidad y la coherencia.
  2. Si bien los recursos comunes (tiempo de trabajo en grupo, oportunidad de votar, etc.) procurarán distribuirse equitativamente entre los productos de trabajo, los voluntarios y miembros financiados generalmente solo se esforzarán al máximo en el desarrollo y la revisión de contenido que refleje sus propios intereses. Esto aplica incluso si un proyecto tiene acuerdos de aceleración con la organización HL7.
  3. El trabajo arduo (y laborioso) del proceso de normalización no consiste en crear los artefactos técnicos, sino en trabajar con las personas: lograr su participación, establecer un entendimiento común, fomentar la colaboración y alcanzar acuerdos. En ocasiones, es posible agilizar el trabajo técnico añadiendo recursos adicionales. Sin embargo, existen limitaciones significativas respecto a la capacidad de estos recursos para acelerar los procesos sociales de implementación, aún más esenciales.
  4. No hay garantías. En un proceso abierto y consensuado, HL7 no puede ofrecer garantías en cuanto a:
    • Resultados: las especificaciones (e incluso el alcance) pueden cambiar con respecto a lo previsto al inicio de un proyecto.
    • Estabilidad: la versión final de un estándar puede tener muy poco en común con la versión inicial. Se producirán cambios según el proceso de revisión y prueba. En ocasiones, estos cambios pueden ser radicales. La estabilidad solo se alcanza cuando la experiencia y el consenso de la comunidad permiten consolidar la especificación (lo que puede tardar varios años como mínimo, y en ocasiones mucho más).
    • Tiempo: HL7 y sus grupos de trabajo tendrán múltiples exigencias de tiempo. Además, es difícil predecir el tiempo necesario para alcanzar el consenso. Los miembros experimentados de HL7 podrían proporcionar estimaciones sobre la duración del proceso, pero los proyectos deben ofrecer amplios márgenes de seguridad para atender las aportaciones o problemas inesperados.
    • Adopción: El proceso de normalización no puede, por sí solo, generar demanda. Puede facilitar el progreso en la satisfacción de las demandas existentes y (en ocasiones) reducir las barreras hasta el punto de que se active una demanda previamente invisible. Incluso si la formación de la comunidad tiene éxito, las circunstancias externas pueden retrasar la implementación o incluso impedirla.
  5. Las normas suelen ser una pequeña pieza del rompecabezas. A menudo se requiere una gestión de cambios significativa para modificar los incentivos del mercado, las prácticas empresariales, las culturas profesionales, los hábitos individuales y, a veces, incluso las regulaciones, de la forma necesaria para obtener los beneficios que se perseguían con una especificación. Considere lo que se puede lograr en el ámbito de la gestión de cambios (y la estrategia para lograrlo) antes de invertir demasiado en una especificación cuyo éxito depende de un cambio significativo.
  6. Parte del poder de los estándares reside en su interacción, y una visión global de la interoperabilidad es una premisa fundamental del proceso de estandarización de HL7. Siempre que sea posible, considere cómo lograr los resultados y objetivos aprovechando el trabajo existente o aprovechando otros proyectos, en lugar de crear algo completamente desde cero. No solo se ahorra en el desarrollo y la revisión de contenido, sino que también se puede aprovechar gran parte de la comunidad existente.
  7. Considere si se podrían lograr mejores resultados con pasos pequeños y graduales que con un solo gran salto (Los grandes saltos a veces funcionan, pero requieren más trabajo y una buena sincronización).

La comunidad HL7 es especial. Está llena de personas muy inteligentes y dedicadas que se apasionan por este espacio. Muchas han adaptado sus carreras profesionales únicamente para poder seguir formando parte de esta comunidad. Nos complace que haya decidido unirse a nosotros y esperamos ayudarle a materializar sus propias ideas para mejorar la atención médica.

Fuente: https://confluence.hl7.org/

Aporte de César Guerreros

Tagged:

Deja una respuesta