O Health Level 7 (HL7) Clinical Document Architecture (CDA) tem base no mesmo Modelo de informações de referência da versão 3 do HL7, usado para desenvolver interações para envio de mensagens do HL7 v3. Enquanto as mensagens do HL7 representam interações individuais de assistência médica (como consultas, respostas e notificações), um documento HL7 CDA é um documento único, persistente que representa uma visita ao paciente, um documento de continuidade de tratamento e coisas do gênero. Para tornar as entradas em um CDA legíveis para as pessoas, cada uma tem uma descrição em texto, além de qualquer conteúdo lido por máquina, como mostra a Listagem 1. As mensagens do HL7 v3 são, no sentido exato, transmitidas por cabo (por exemplo, como parte de uma interação cliente-servidor ou distribuição de dados servidor-servidor). Como elas também precisam ser lidas por humanos, os documentos do HL7 CDA podem ser transferidos por outros meios, como e-mail.

<component>
    <section>
        <code code="10155-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <title>Allergies and Adverse Reactions</title>
        <text>
            <list>
                <item>Penicillin - Hives</item>
            </list>
        </text>
        <entry>
            <observation classCode="OBS" moodCode="EVN">
                <code xsi:type="CD" code="247472004" codeSystem="2.16.840.1.113883.6.96"
                    codeSystemName="SNOMED CT" displayName="Hives"/>
                <statusCode code="completed"/>
                <entryRelationship typeCode="MFST">
                    <observation classCode="OBS" moodCode="EVN">
                        <code xsi:type="CD" code="91936005"
                            codeSystem="2.16.840.1.113883.6.96"
                            codeSystemName="SNOMED CT"
                            displayName="Allergy to penicillin"/>
                        <statusCode code="completed"/>
                    </observation>
                </entryRelationship>
            </observation>
        </entry>
    </section>
</component>

Há vários anos, o analisador Saxon suporta transformações de XSLT 2.0 no lado do servidor. Recentemente, na conferência de 2011 sobre XML em Praga, Dr. Michael Kay, que escreveu o analisador Saxon original, apresentou uma versão alfa do Saxon Client Edition (Saxon-CE), que permite a execução de transformações de XSLT 2.0 diretamente do aplicativo cliente da Web (no navegador). O Saxon-CE usa JavaScript para executar em qualquer navegador moderno, o que tem sido um problema contínuo com XSL no lado do cliente. Historicamente, o suporte a XSL não foi implementado de forma consistente pelos diferentes navegadores. Como ele usa JavaScript como um mecanismo de tempo de execução, o Saxon-CE resolve esse problema.

Além disso, o XSLT 2.0 fornece vários recursos que não eram suportados na especificação XSLT 1.0 original, como o suporte para diversos documentos e digitação de dados mais sólida. Com o Saxon-CE, esses recursos são suportados no cliente, e, como este artigo demonstra, alguns desses recursos são adequados para uso em exibições do aplicativo do cliente—em particular, no suporte no lado do cliente para diversos documentos.

Introdução

Para desenvolver o aplicativo CDA Viewer descrito neste artigo, eu usei o servidor da Web Unite que vem embalado com a versão mais recente do Opera. É possível usar qualquer servidor de aplicativos que preferir. Como estou descrevendo como desenvolver uma exibição de aplicativo cliente, eu não descrevo como o documento CDA é persistido ou distribuído. Para testar a exibição de aplicativo, eu simplesmente publico um exemplo de CDA como uma URL diretamente pelo servidor da Web (como alternativa, é possível persistir em um banco de dados XML como o IBM® DB2® pureXML). Da mesma forma, minhas transformações XSL são publicadas como URLs.

Fazendo o download do Saxon-CE

A versão alfa do Saxon-CE está atualmente disponível para download no site da Saxonica (consulte Recursos para obter um link). Essa versão alfa não é destinada a aplicativos de produção no momento, no entanto, com base no sucesso do analisador Saxon original, não há dúvidas de que o Client Edition também se tornará rapidamente um padrão do segmento, especialmente se receber um feedback positivo dos primeiros usuários.

A versão alfa vem com notas de versão abrangentes. É possível copiar os arquivos JavaScript contidos na pasta de versão descompactada para seu servidor de aplicativos, como você faria com qualquer outro script .js. Também reserve um tempo para fazer o download dos aplicativos de exemplo. O JavaScript é composto por um único arquivo .nocache.js junto com um número de arquivos .js reduzido—, um para cada navegador principal. Esses arquivos contêm o código do analisador; o arquivo .nocache.js detecta qual navegador está sendo usado e chama o script .js apropriado. Os exemplos de aplicativo são compostos por um arquivo de transformação XSL, alguns dados XML e um arquivo HTML que chama o JavaScript do Saxon-CE para executar a transformação. O aplicativo CDA Viewer criado segue o mesmo padrão, embora a camada de transformação tenha sido dividida em três arquivos para melhorar a legibilidade (consulte Download). Em meu servidor da Web, há uma pasta para cada um dos exemplos de aplicativo e outra para meu aplicativo CDA.

Voltar para parte superior

Explorando os recursos no XSLT 2.0

Muitos recursos foram introduzidos na especificação XSLT 2.0—recursos como definições de função, diversos documentos de resultado, sequências e árvores temporárias, digitação mais sólida e análise de texto. Este artigo destaca o suporte para diversos documentos de resultado. No lado do servidor, usar diversos documentos de resultado significa criar diversos documentos no servidor, de modo que você possa criar uma página inicial XHTML que faz referência a diversas outras páginas de resultado, todas geradas no servidor. No contexto da transformação no lado do servidor, o uso de diversos documentos de resultado significa apenas isso: diversos documentos. A Listagem 2 demonstra essa abordagem. Quando você gera diversos documentos no lado do cliente usando o Saxon-CE, o conteúdo gerado é destinado a diferentes áreas da tela de seu aplicativo cliente (tipicamente, elementos div na página HTML).

<xsl:for-each select="section">
    <xsl:result-document href="{@id}.html">
        <xsl:apply-templates select="." mode="html" />
    </xsl:result-document>
</xsl:for-each>

Voltar para parte superior

Transformando o documento clínico

Organizei minhas transformações XSL em três arquivos (consulte Download):

• cda.xsl. Contém a transformação básica para exibir o documento legível
• cda-machine-readable.xsl. Contém uma camada personalizável que exibe atualmente os detalhes do documento lidos por máquinas de uma maneira mais organizada
• cda-dom-interaction.xsl. Contém modelos que lidam com interações com a página DOM do HTML, como eventos de clique

Além disso, há um arquivo CSS e a própria página HTML.

O CSS é direto. A página HTML é direta da mesma forma, contendo um número de elementos div para as diferentes áreas da tela do CDA Viewer, cada um posicionado por um ID no CSS. O plano é carregar todo o CDA e transformá-lo e, em seguida, permitir o acesso interativo por meio do DOM de modo que o elemento div seja chamado div-cache, escondo na parte inferior do visualizador. Esse cache contém uma cópia das entradas registradas no CDA. É possível rolar a tela para baixo e ver esse texto, ou ocultar esse elemento marcando-o style="visibility:hidden;inline:none".

O código na Listagem 3 aciona o processo de transformação. Como é possível ver, as tags <script> chamam primeiro o JavaScript do Saxon-CE e, em seguida, a folha de estilo de transformação XSL, visando o documento CDA.

<script type="text/javascript" language="javascript" src="../Saxonce.nocache.js"></script>
<script type="application/xslt+xml" language="xslt2.0" src="cda.xsl"
                      input="SampleCDADocument.xml"></script>

Exibindo o índice do CDA Viewer

Na Listagem 3, a principal transformação cria primeiro um cabeçalho simplificado para o CDA Viewer extraindo algumas das informações do wrapper do CDA. Agora, é possível ver xsl:result-document em ação. Na Listagem 4, perceba como a tag <div> é prevista por seu ID #creation . method="ixsl:replace-content" é a abreviação de Saxon-CE para "no XSL interativo, substitua o conteúdo". Você verá um exemplo no momento de anexar o conteúdo. Perceba que quando você lida diretamente com o CDA, é necessário usar o namespace hl7: sempre que você se referir a um elemento no CDA. Você verá mais tarde que isso não é necessário quando lida com modelos que fazem referência ao DOM. Esse processo pode ser complicado e esse é um motivo pelo qual os modelos foram separados em várias folhas de estilo XSL.

<xsl:result-document href="#creation" method="ixsl:replace-content">
    <div>
        <xsl:value-of>
            <xsl:value-of select="hl7:ClinicalDocument/hl7:title"/>:
            <xsl:value-of
              select="hl7:ClinicalDocument/hl7:recordTarget/hl7:patientRole/hl7:patient"/>
        </xsl:value-of>
    </div>
</xsl:result-document>

Na próxima parte do código de mesmo arquivo XSL (consulte Listagem 5), é possível ver como o índice do CDA Viewer é gerado a partir das seções no documento CDA. Observe os arquivos de exemplo fornecidos para obter detalhes sobre como o índice é formatado. Uma abordagem parecida é usada para armazenar em cache os dados de entrada clínica do CDA. Em ambos os casos, é possível ver como os resultados são anexados ao conteúdo existente do elemento <div> de destino, sempre que o modelo for aplicado.

<xsl:result-document href="#notes" method="ixsl:append-content">
    <xsl:apply-templates select="//hl7:component/hl7:section" mode="notes"/>
</xsl:result-document>

<xsl:result-document href="#div-cache" method="ixsl:append-content">
    <xsl:apply-templates select="//hl7:component/hl7:section" mode="cache"/>
</xsl:result-document>

Figura 1 mostra o CDA Viewer básico e o índice.

Interagindo com o DOM

IDs gerados são usados para conectar links no índice para as entradas do CDA armazenados em cache. Listagem 6 fornece um trecho do modelo usado para criar uma entrada no índice.

<a class="notes-section">
    <xsl:attribute name="id"><xsl:value-of select="generate-id(.)"/></xsl:attribute>
    <xsl:value-of select="hl7:title"/>
</a>

Na Listagem 7, perceba como o atributo mode="ixsl:onclick" no modelo é usado para informar ao Saxon-CE que aplique esse modelo para lidar com um evento de clique. Isso não é diferente de qualquer outro evento de clique do JavaScript: Ele é simplesmente manipulado pelo Saxon-CE e pela folha de estilo XSL. Observe que sempre que o analisador lida com um evento de clique como esse, o contexto muda do documento XML original para o DOM da página HTML e, por isso, esses modelos foram separados em uma folha de estilo de transformação chamada cda-dom-interaction.xsl. O próprio modelo exibe o texto da entrada CDA, extraído do cache criado anteriormente usando o ID associado ao evento de clique original (o ID do link de âncora original). Este texto substitui o conteúdo no documento de resultados note-detail do elemento div. Em seguida, o modelo aplica quaisquer modelos de downstream aplicáveis para lidar com o conteúdo lido por máquinas na entrada CDA.

<xsl:template match="a[@class='notes-section']" mode="ixsl:onclick">
    <xsl:variable name="div-id" select="@id"/>
    <xsl:variable name="selected-section"
        select="//div[@id='div-cache']/div[@id=$div-id]/section"/>

    <xsl:result-document href="#note-detail" method="ixsl:replace-content">
        <h2><xsl:value-of select="$selected-section/title/text()"/>
            (<xsl:value-of select="$div-id"/>)</h2>
        <div><xsl:value-of select="$selected-section/text"/></div>
        <h2>Machine-readable Content</h2>
        <xsl:apply-templates select="$selected-section" mode="mach-read">
            <xsl:with-param name="a" select="."/>
        </xsl:apply-templates>
    </xsl:result-document>
</xsl:template>

Para manter as questões de legibilidade por máquina e por humano separadas, foi criada e incluída uma terceira folha de estilo de transformação chamada cda-machine-readable.xsl. Manter esses modelos separados tem a vantagem de que essa terceira folha de estilo pode ser estendida ou completamente substituída para usar uma folha de estilo mais sofisticada para lidar com as informações legíveis por máquinas no CDA. Talvez você queira fazer isso, por exemplo, para fornecer tabelas mais incrementadas ou representações gráficas dos dados ou para reter determinados tipos de entradas. Como alternativa, talvez você queira ir mais fundo e carregar outro documento XML, talvez de um repositório de metadados, e expandir alguns dos códigos dentro dos dados legíveis por máquina ou categorizá-los usando sistemas de código comuns. Impedir os modelos de transformar entradas legíveis por máquinas é uma boa prática de programação, assim como a separação das questões em geral. Considero essa prática essencial ao lidar com transformações de larga escala ou aquelas que eu espero que cresçam.

Exibindo entradas clínicas legíveis por máquinas

Minha folha de estilo minimalista de transformação legível por máquina contém um único modelo que identifica vários tipos de entradas (eventos de Observação, Administração de substância, Procedimento e Ação) e estilos conhecidos e usa listas com marcadores e tabelas. Não tentei realizar nada muito sofisticado aqui, mas é um exercício útil observar como um modelo simples pode fornecer um retorno substancial em estilo e organização. Perceba também como na Listagem 8 o link de âncora originador é passado para o modelo usando um parâmetro. Essa etapa não exige a exibição dos dados legíveis por máquina. Em vez disso, o link é passado por esse modelo e armazenado em cache para uso posterior em um elemento div oculto na parte inferior do detalhe da entrada. As informações desse link serão usadas depois para criar o que é chamado de uma área de fixação. Em nome da brevidade, tudo foi omitido, com exceção de xsl:when para Observação em xsl:choose.

<xsl:template match="section" mode="mach-read">
    <xsl:param name="a"/>

    <div id="mach-read">
        <xsl:choose>
            <xsl:when test="entry/observation">
                <h3>Observations</h3>
                <ul>
                    <xsl:for-each select="entry/observation">
                        <li><a>
                            <xsl:value-of select="text"/>
                            <xsl:value-of select="code/@displayName"/>
                            <xsl:for-each select="value">
                            (<xsl:value-of><xsl:value-of select="@value"/>
                                <xsl:value-of select="@unit"/></xsl:value-of>)
                            </xsl:for-each>
                        </a></li>
                    </xsl:for-each>			
                </ul>
            </xsl:when>
            <xsl:otherwise>(no match)</xsl:otherwise>
        </xsl:choose>
        <div class="xref" style="visibility:hidden;inline:none">
            <xsl:copy-of select="$a"/>
        </div>
    </div>
</xsl:template>

Perceba que, como esse modelo é aplicado a uma cópia dos dados CDA originais armazenados em cache no DOM, o hl7: não é exigido para elementos como entry, code e observation. Se você quiser, será possível adicionar esse namespace às entradas CDA armazenadas em cache, mas há pouco benefício em fazer isso, pois nenhuma serialização adicional será realizada. Se houver qualquer ambiguidade entre os elementos HL7 CDA e outros elementos na página, fazer isso seria considerado pragmático.

Figura 2 mostra o CDA Viewer exibindo um evento de observação representando alergias e reações adversas.

Voltar para parte superior

Desenvolvendo um novo padrão de design: a área de fixação

A área de fixação é um padrão de design que surgiu durante o desenvolvimento dessas transformações, inspirada pela forma que o Saxon-CE implementa os documentos resultantes do XSLT 2.0. Como foi descrito anteriormente, o conteúdo gerado pode ser anexado a uma área da tela ou pode substituir um conteúdo existente. Normalmente, convém substituir o conteúdo existente, no entanto, quando você estiver aplicando um modelo repetidamente, convém anexar o conteúdo. Se você aplicar vários modelos à mesma área da tela de destino, será possível criar uma coleção que lembra um marcador. É possível adicionar interativamente a essa coleção sem remover qualquer conteúdo existente na área da tela.

No exemplo de código na Listagem 9, observe o modelo para fixar links de âncora. É claro que este é um exemplo de aplicativo, mas a ideia aqui é intrigante. Ao clicar no link do índice do Viewer, o evento de clique é manipulado, exibindo o conteúdo dessa seção do CDA. Ao clicar em qualquer outro link, no entanto, um simples modelo de âncora lida com o evento de link e copia o conteúdo do link na área de fixação. Como resultado, é possível usar o Viewer para alternar entre os conteúdos do documento clínico e "fixar" entradas para referência posterior.

<xsl:template match="a" mode="ixsl:onclick">
    <xsl:variable name="div-mach-read" select="ancestor::div[@id='mach-read']"/>
    <xsl:result-document href="#pin" method="ixsl:append-content">
        <div>
            <xsl:attribute name="title"><xsl:value-of select="$div-mach-read/h3"/>
            - <xsl:value-of select="text()"/></xsl:attribute>
            <xsl:copy-of select="$div-mach-read/div[@class='xref']/a"/> -
            <xsl:value-of select="text()"/>
        </div>
    </xsl:result-document>
</xsl:template>

Figura 3 mostra a área de fixação em uso.

Os benefícios desse padrão de design aumentarão, é claro, se você puder fazer algo útil com as entradas fixadas, no entanto, essa discussão ultrapassa o escopo deste artigo. Um possível caso de uso pode envolver um plug-in para um navegador de e-mail que permite a um paciente exibir um CDA recebido do profissional, fixar algumas entradas e colocá-las em uma resposta de e-mail. Como eles lidam com as informações de forma declarada, o Saxon-CE e o XSLT 2.0 comprovarão que são ferramentas úteis para o desenvolvimento desses aplicativos.

Voltar para parte superior

Conclusão

Os documentos CDA são persistentes e, como resultado, normalmente são bastante grandes. Apesar de serem legíveis por humanos, os documentos CDA também contêm muitas informações legíveis por máquinas, o que pode se tornar mais gerenciável pela transformação em uma exibição de cliente expandida. Tenho certeza de que com os releases futuros, o Saxon-CE provará ser uma ferramenta essencial para fazer exatamente isso, pois pode executar em qualquer navegador moderno, além de oferecer recursos de XSLT 2.0 no lado do cliente, como suporte para diversos documentos de resultado. Eu espero realmente que essa tecnologia se torne indispensável para os desenvolvedores de aplicativos avançados de assistência médica.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• XML for Data: XSLT 2.0: An early look" (Kevin Williams, developerWorks, julho de 2002): revisa muitos dos recursos do XSLT 2.0 e exemplos de código que mostra quão útil essa linguagem de estilo XML pode ser.
  
  
• Compiling Saxon using GWT (Dr. Michael Kay, Saxon diaries, novembro de 2010): nessa entrada de blog, saiba como o analisador Saxon foi portabilizado do Java™ para JavaScript usando o Google Web Toolkit.
  
  
• The HL7 Clinical Document Architecture: saiba mais sobre o HL7 CDA no Journal of the American Medical Informatics Association.
  
  
• HL7 version 3: Message or CDA Document?: saiba mais sobre as diferenças entre a mensagem HL7 v3 e o CDA neste artigo informativo sobre Ringholm.
  
  
• Mais artigos desse autor (Piers Michael Hollott, developerWorks, novembro de 2010-atual): leia artigos sobre DITA e outras tecnologias.
  
  
• Iniciante em XML? Obtenha os recursos que precisa para aprender XML.
  
  
• Área de XML do developerWorks: localize os recursos necessários para avançar em conhecimentos na arena XML, incluindo DTDs, esquemas e XSLT. Consulte Biblioteca técnica de XML para obter um intervalo amplo de artigos técnicos e dicas, tutoriais, padrões e IBM Redbooks.
  
  
• Certificação XML da IBM: Descubra como se tornar um Desenvolvedor Certificado pela IBM em XML e tecnologias relacionadas.
  
  
• eventos técnicos e Webcasts do developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
  
  
• o developerWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
  
  
• Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
  
  
• Demos on demand do developerWorks: Acompanhe demos que abrangem desde a instalação de produto e configuração para iniciantes até funcionalidade avançada para desenvolvedores experientes.
  
  

Obter produtos e tecnologias

• Saxon-CE Faça o download da versão alfa no Web site da Saxonica, junto com aplicativos de amostra e documentação.
  
  
• XML Prague 2011 (arquivo PDF): faça o download dos procedimentos da conferência.
  
  
• Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste on-line no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  

Discutir

• Fóruns de discussão da zona de XML: Participe de qualquer uma das várias discussões relacionadas a XML.
  
  
• A função de adição da visualização comunidade do developerWorks: Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Explorando os recursos no XSLT 2.0
• Transformando o documento clínico
• Desenvolvendo um novo padrão de design: a área de fixação
• Conclusão
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais