O padrão de sistema de mensagens do HL7 procura fornecer uma estrutura abrangente para suportar todas as áreas do segmento de mercado de assistência médica, gerando e publicando XSDs do W3C de amostra e modelos gerados a partir modelo de objeto subjacente, que engloba diversos projetos. Outros frameworks de normatização, como o National Information Exchange Model (NIEM), dão mais ênfase aos conceitos de extensão e restrição para facilitar a adoção de novos segmentos de mercado e práticas. Embora eu considere útil para estender efetivamente os esquemas publicados do HL7 v3 usando a linguagem de validação ISO Schematron para complementar o esquema original, creio que é possível usar o OASIS CAM propriamente dito — que se baseia fortemente na extensão e restrição — para o mesmo fim. O CAMProcessor (consulte Download), uma implementação de software livre Java ™ de CAM, fornece um IDE para ingerir, estender e substituir os esquemas de release do HL7. Depois de criar um modelo de CAM usando o CAMProcessor, é possível gerar facilmente um conjunto de mensagens de conformidade a partir do modelo.
Sempre que um novo padrão de sistema de mensagens do HL7 é lançado, os implementadores precisam "decifrá-lo", analisando os XSDs lançados e o modelo subjacente. Normalmente, um dos produtos dessa análise é um conjunto de mensagens de conformidade que representam as interações esperadas e a interoperabilidade do aplicativo que implementa essas interações. Além disso, muitas vezes é necessário alterar os XSDs para alinhá-los melhor com o modelo de objeto subjacente. Esse processo fica muito mais simples se você usa a ferramenta CAMProcessor para ingerir e estender os esquemas lançados em modelos de CAM. Conforme explicarei mais adiante neste artigo, cardinalidade e opcionalidade — ou força de conformidade — são duas áreas que frequentemente requerem atenção específica.
Estendendo um esquema pela ingestão de um XSD
Os tutoriais que são oferecidos com o projeto CAMProcessor são úteis para configurar e executar o aplicativo. Basicamente, você assimila um arquivo XSD criando um novo arquivo de modelo de CAM a partir de um XSD já existente e, em seguida, modifica o arquivo para excluir elementos e atributos desnecessários que podem estar ausentes no XSD. Depois de criar um modelo de CAM, é possível incluir anotações para fornecer dados de amostra e exportar um arquivo de sugestões (ou incluir dados de amostra diretamente no modelo). Com um modelo de CAM e um arquivo de sugestões, você pode criar arquivos simples, que em seguida podem ser usados para fins de conformidade.
Por exemplo: em uma mensagem HL7, como as incluídas como arquivos de amostra neste arquivo, talvez seja necessário excluir elementos de valor referentes a itens codificados, incluir atributos de raiz e extensão e excluir atributos que existem como artefatos do processo de geração do XSD original. É possível configurar dados de amostra nos wrappers Transport e Control Act (que envelopam a carga útil da mensagem) no próprio modelo, sendo que você deve configurar dados de amostra na carga útil da mensagem usando anotações mantidas em um arquivo de sugestões separado.
Primeiro, selecione um esquema para ingerir. Já que os esquemas HL7 são compostos, talvez você tenha muitas opções de elementos para escolher. Estou selecionando um esquema PRPM_IN306050CA, que define uma consulta de provedor de assistência médica. Depois de selecionar um esquema, você ainda precisa selecionar um elemento-raiz dentro do esquema. Normalmente, os esquemas HL7 possuem apenas um elemento-raiz para escolher, que tem o mesmo nome da interação. Novamente, eu seleciono PRPM_IN306050CA, como pode ser visto naFigura 1.
Figura 1. Selecionando um XSD para ingerir no CAMProcessor
Por enquanto, eu uso as configurações padrão no restante das opções. Para fazer isso, clique em OK e, depois de aproximadamente um minuto, você terá criado um modelo de CAM a partir do XSD. Pode-se clicar no link OK que aparece na guia Progress para abrir o novo modelo. Nesse ponto, é recomendável salvar uma cópia do modelo de CAM sem modificações. Depois de fazer isso, é possível voltar a esse modelo sem precisar reingerir o XSD original. Pode-se ver o modelo de CAM sem modificações na Figura 2.
Figura 2. Modelo de CAM sem modificações
Estendendo e restringindo atributos e elementos
O primeiro passo para estender o esquema original é remover atributos e elementos desnecessários que são artefatos da geração da programação do XSD original. Por exemplo: quero remover os elementos realmCode e InfraStructureRootAttributes, que eu não quero nas mensagens de conformidade definitivas.
Para remover o elemento realmCode , selecione-o na guia Structure
, que exibe o modelo de CAM e, no menu sensível ao contexto acionado com o botão direito, selecione Add New Rule. No assistente Add New Constraint (veja a Figura 3), selecione excludeElement na lista suspensa Action e, como você quer excluir todas as ocorrências desse elemento, limpe a caixa de seleção Parent de forma que somente a caixa de seleção All esteja selecionada. O CAMProcessor facilita o trabalho com o XPath.
Figura 3. Excluindo um
realmCode no modelo de CAM
No modelo de CAM de consulta do provedor, eu removo todos os elementos do elemento queryByParameter , com exceção do elemento parameterList , porque esses elementos pertencem à mensagem de resposta, que é retornada por um aplicativo após a realização da consulta. Esses elementos externos estão presentes na mensagem da consulta porque os componentes comuns do esquema são usados nos esquemas XSD da consulta e da resposta. A exclusão desses elementos é semelhante à exclusão de outros elementos e atributos. Eu uso o XPath completo e a ação excludeTree para excluir totalmente um único fragmento de árvore. Por outro lado, elementos como controlActEvent devem ter a opcionalidade removida porque são sempre obrigatórios.
Da mesma forma. é possível incluir a ação axcludeAttribute para excluir todos os atributos InfrastructureRootAttributes do documento. Todos os elementos que apresentam %type=II% são identificadores de instância — normalmente, são elementos ID ou value .
Infelizmente, embora esses elementos devam ser identificados por meio de uma raiz e uma extensão — portanto, você os inclui selecionando o elemento em questão, clicando com o botão direito e selecionando Add Child Attribute para incluir uma raiz e um atributo de extensão (como na Figura 4). Ao mesmo tempo, é possível editar o texto do elemento ID ou value para remover o texto de amostra (%type=II%), deixando o elemento sem preencher, com dois atributos.
Figura 4. Incluindo um atributo filho no modelo de CAM
Injetando dados usando um arquivo de sugestões
É possível configurar elementos e atributos nas seções Message Transport e Control Act Wrapper diretamente nos valores padrão configurados para o modelo de CAM, já que são iguais para cada mensagem de conformidade que é gerada. Neste ponto, pode-se gerar uma mensagem de amostra que contém um Message Transport and Control Act Wrapper totalmente preenchido e sem dados na lista de parâmetros.
Para gerar uma mensagem de amostra, selecione Export Examples no menu File Export . Eu escolhi não mostrar nenhum elemento opcional e nenhum arquivo de sugestões (por enquanto). A Figura 5 mostra o formulário Generate Examples sem nenhum arquivo de sugestões selecionado.
Figura 5. Exportando um exemplo de mensagem HL7 a partir do modelo de CAM
Agora só falta criar um arquivo de sugestões para incluir alguns dados na sua consulta. Para realizar essa tarefa por meio do IDE, clique com o botão direito em um elemento ou atributo e selecione Edit Annotations. Inclua uma guia Value na sua anotação, juntamente com uma lista de elementos de dados separados e terminados por uma barra vertical (|) como na Figura 6.. Depois de incluir anotações em todos os elementos e atributos que requerem dados nas suas mensagens de conformidade, é possível exportar sugestões a partir do menu File. Agora, quando você exporta exemplos, pode fornecer esse arquivo de sugestões e os seus dados são incluídos nas mensagens exportadas.
Figura 6. Editando anotações de CAM para incluir dados de amostra
Lidando com a cardinalidade e opcionalidade do HL7
As forças de conformidade do HL7 v3 vão de Not Permitted e
Optional, que representam elementos que não devem estar presentes em uma mensagem e elementos que não precisam ser suportados, a Required e Mandatory, que representam elementos que devem ser suportados, mas podem estar ausentes em uma determinada instância, e elementos que devem ser suportados e estar presentes independentemente de qualquer coisa, respectivamente. No Canadá, adotou-se uma força de conformidade de Populated para preencher a lacuna entre Required e Mandatory, representando um elemento que deve ser suportados com dados (não pode estar vazio). A Tabela 1 mostra as forças de conformidade do HL7 v3 e as ações que podem ser usadas para representar esses elementos em um modelo de CAM.
Tabela 1. Forças de conformidade do HL7 v3
| Força de conformidade | Descrição | Regra de CAM |
|---|---|---|
| Not permitted | Esse elemento não deve aparecer nunca nas mensagens. Os aplicativos podem emitir um erro se o recebem. | excludeElement |
| Optional | Um elemento que pode ser suportado pelos aplicativos se eles optarem por fazer isso. Se não é suportado, o elemento deve ser ignorado caso seja recebido. | excludeElement ou makeOptional, dependendo da opção do fornecedor |
| Required | Um elemento que deve ser suportado pelos aplicativos, mas não precisa, necessariamente, estar presente em uma determinada mensagem. | makeOptional |
| Populated | Um elemento preenchido deve ser suportado pelos aplicativos e deve aparecer sempre, mas pode aparecer como elemento vazio com um sabor null (por exemplo: nullFlavor="UNK" indicando que as informações necessárias são desconhecidas). | makeMandatory, makeNillable |
| Mandatory | Um elemento obrigatório (mandatory) deve ser suportado e deve aparecer sempre com um valor não nulo. | makeMandatory |
A força de conformidade Populated foi adotada pela Infoway, que mantém o padrão HL7 no Canadá, para fazer a diferenciação entre as cardinalidades da forma [0..N] e da forma [1..N]; ambas são Required. Esses elementos são mais do que Required e menos do que Mandatory. Essa distinção é inerente ao padrão internacional, mas se tornou mais explícita no padrão pan-canadense.
No contexto de um registro clínico, essa última força de conformidade parece particularmente obtusa: um elemento como endereço ou segundo nome ou está presente ou não está, e elementos como sexo, sobrenome ou identificador pessoal sempre devem estar presentes. Entretanto, o padrão de sistema de mensagens HL7, cobre várias áreas além dos registros clínicos e, no contexto de dados farmacêuticos ou de laboratórios de diagnóstico, obviamente há uma grande diferença entre os dados que estão ausentes porque são retidos por motivos de segurança, dados que estão ausentes porque são desconhecidos e dados ausentes porque indicam um resultado de diagnóstico caracterizado como "falso". O sistema de mensagens HL7 deve ser capaz de dar conta de todos esses cenários, o que leva a uma proliferação de forças de conformidade.
Diferenciando dados de conformidade usando o OASIS CAM
Parte da confusão relacionada às forças de conformidade do HL7 procede da sua forma de implementação nos esquemas de release. Pode ser difícil diferenciar os elementos identificados como Optional e os elementos identificados como Required somente pelos esquemas XSD e, nesse caso, é necessário voltar ao arquivo Model Interchange Format (MIF) (que também faz parte do release). Como o OASIS CAM é mais expressivo que o XSD, ele representa melhor essas forças de conformidade da forma que podem ser aplicadas a um aplicativo de assistência médica, como na Tabela 1.
Depois de usar um modelo do OASIS CAM para estender um XSD já existente e criar mensagens de conformidade baseadas nessa extensão, é possível comprimir o modelo de CAM (o que remove todas as árvores e itens excluídos) e criar um novo XSD a partir do modelo. Esse processo é menos arriscado do que fazer as mudanças diretamente no XSD e deve suportar fornecedores e implementadores que talvez queiram obter alguns dos benefícios de conformidade da abordagem de CAM, mas, no fim das contas, desejam continuar usando os XSDs do W3C.
Entretanto, para os fornecedores e implementadores de assistência médica que querem adotar a abordagem de CAM de forma mais completa, deve ser possível extrair informações diretamente da descrição, no MIF, de uma interação HL7 (que convenientemente também é armazenada no formato XML) e injetar esses detalhes nos modelos de CAM que foram ingeridos, para estendê-los ainda mais. Essa abordagem alinha melhor o padrão de sistema de mensagens do HL7 à abordagem de extensão e restrição tipificada pelo NIEM e permanece fiel à abordagem interdisciplinar recomendada pelo HL7.
O HL7 v3 é um padrão em evolução que pode representar um alvo móvel. Para suportar vários releases, é necessário recriar conjuntos de mensagens de conformidade. Usando a abordagem oferecida pelo CAMProcessor, você verá que irá passar menos tempo reinventando a roda e mais tempo se concentrando na lógica de negócios subjacente às mensagens que você suporta. Como alternativa, se você desenvolver a funcionalidade de adotante inicial, esse tipo de abordagem poderá ajudá-lo a se "desacoplar" do alvo móvel, permitindo que você se adapte às mudanças inevitáveis que ocorrem quando se trabalha com um padrão em evolução.
| Descrição | Nome | Tamanho | Método de download |
|---|---|---|---|
| Extended and Modified CAM Templates | downloads.zip | 28KB | HTTP |
Informações sobre métodos de download
Aprender
- Meet CAM: A new XML validation technology (Brian M. Carey, developerWorks, setembro de 2009): melhore o nível da validação semântica e estrutural com esta introdução útil ao OASIS CAM e às diferenças entre essa abordagem e outros esquemas.
- Estrutura de Validação XML usando OASIS CAM (CAMV) (Puneet Kathuria, David Webber, Martin Roberts; developerWorks, maio 2010): explore um exemplo prático do uso de modelos de CAM para suportar o sistema de mensagens da cadeia de fornecimento no segmento de mercado automotivo.
- Taking XML Validation to the Next Level (Michael Sorens, devX, março de2009): leia uma grande série que apresenta vários recursos do OASIS CAM.
- Understanding HL7 Version 3 from a developer perspective (Vishnu's Blog, Sun, agosto de 2007): confira uma discussão informativa sobre alguns dos fatores diferenciais entre as versões 2 e 3 do HL7.
- Schema-based code generation" (HL7 International): leia uma entrada de wiki que descreve a opinião do HL7 International em relação aos esquemas de release do HL7 v3 e fornece recomendações sobre o uso dos esquemas e modelos subjacentes.
- Área de XML do developerWorks: Obtenha os recursos necessários para melhorar suas qualificações na esfera de XML.
- IBM developerWorks Industries: Consulte este site para conferir todos os mais recentes recursos técnicos para desenvolvedores específicos do segmento de mercado.
- My developerWorks: Personalize sua experiência no developerWorks.
- Certificação XML da IBM: Descubra como se tornar um Desenvolvedor Certificado pela IBM em XML e tecnologias relacionadas.
- Biblioteca técnica de XML: Consulte a zona de XML para obter uma ampla gama de artigos técnicos e dicas, tutoriais, padrões e Redbooks da IBM. Leia também mais dicas de XML.
- eventos técnicos e webcasts do developerWorks
: Mantenha-se atualizado em relação à tecnologia nessas sessões.
- 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
- Projeto jCAM: faça o download desse projeto de software livre que contém o aplicativo CAMProcessor.
- 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 à XML.
- A comunidade do developerWorks: Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.