Transformando a indústria da saúde através de API Marketplaces

Porque a saúde precisa de API Marketplaces?

A indústria da saúde é uma das pioneiras em adoção tecnológica. Devido a isso houve uma aproximação maior dos usuários aos dados, permitindo um rápido acesso aos processos de tomada de decisão e criando uma gradual melhoria na expectativa de vida e saúde da população. Fica evidente que a qualidade e a disponibilidade de dados na indústria da saúde tem um papel importante na transparência e do foco no paciente. De acordo com o Stanford Medicine 2017 Health Trends, a quantidade de dados eletrônicos de saúde (Eletronic Medical Record,EMR) tem crescido significamente na última década. Existem muitas razões pelas quais os governos estão criando iniciativas com o objetivo de "uso em prol da sociedade", onde os extensos dados de saúde eletrônicos são exportados diretamente de equipamentos (Raio-x, tomógrafos, etc.) e monitores pessoais (Fitbit, Apple Watch, etc).

O principal problema na indústria da saúde é que esses dados valiosos para análise do paciente não estão disponíveis, nem mesmo os gerados pela população, que só ficam acessíveis pelos usuários e não são utilizados de uma maneira efetiva. Empresas privadas e instituiçẽs de saúde são donos destas informações hoje e as mantém subutilizadas.

Esse artigo discute o uso de API Marketplaces como uma solução para esse problema. Através de uma API Marketplace, nós podemos expor estes dados de forma segura e permitir o acesso por empresas privadas de saúde, assim como os usuários, melhorando a eficiência na indústria e habilitando a inovação para a população, utilizando novas tecnologias para o cuidado com a saúde.

O problema da quantidade exacerbada de dados

Ter uma grande quantidade de dados é um "excelente problema". Em muitos casos as indústrias sofrem com a falta de dados para qualquer análise significativa, porém a área da saúde está a frente nesse sentido, atualmente, muitas empresas e instituições de saúde em todo mundo, resumem estes dados e tomam decisões baseados nestas informações. Esse tipo de dado normalmente está registrado em um ou mais sistemas EMR, dependendo do tamanho da organização, e geralmente ficam isolados dentro da instituição, ou até mesmo de uma única aplicação. Não vemos a disponibilidade dessas informações muito menos uma maneira de consumi-las. Se tentássemos ir um pouco mais a fundo no problema encontraríamos alguns desafios. Primeiramente, as aplicações de saúde e as instituições não priorizam os dados além de próprio escopo e em segundo lugar, a população não conseguiria transformar estes dados em informação como se encontram.

Olhando para as aplicações de saúde no geral, vemos um alto nível de especialização das plataformas EMR usadas em institutos de cuidado ao câncer, diabetes, cardiologia ou pediatria. Por essa razão, uma visão focada no paciente é de grande importância.

O motivo de não podermos compartilhar os dados reais é o resultado das políticas de proteção de dados dos usuários. Devido aos cuidados com os dados, a maioria dos países possui diretivas como a HIPAA, para proteger a confidencialidade dos registros de saúde. Assim, os dados originais dos EMR's não podem e nem devem ser expostos. Semter essa real intenção, essas políticas levaram os dados de saúde a ficarem presos dentro das organizações especializadas em assistência médica.

Um indicador positivo é que as plataformas EMR modernas são orientadas por API, aderindo aos padrões de interoperabilidade como HL7 e FHIR para expor os dados clínicos. Entretanto, essas iniciativas de padronização de acesso a dados, não estão resolvendo o problema de acesso a dados. .

Outra oportunidade que tem sido negligenciada é o potencial do crowdsourcing na indústria da saúde. Não vemos muitas startups de saúde focando na população, isso ocorre devido a uma série de barreiras, ou mais importante, a barreira de acesso a informações. Se os dados de saúde fossem mais democratizados e expostos de uma maneira consumível, isso levaria a uma grande inovação, beneficiando a todos os envolvidos.

API Marketplaces como solução

As APIs são vistas como conectores digitais nas atuais plataformas de mercado. As organizações dessas indústrias possuem foco nas plataformas API e estamos vendo isso na área da saúde também. Padrões como o FHIR cobrem a maioria dos dos modelos de dados disponibilizados pelas plataformas. Porém, a principal peça que falta é a disponibilidade dos mercados de API e um ecossistema baseado em gateways. Um API Marketplace resolve especificamente o problema da exploração de dados de saúde se conectando com as partes interessadas, fortalecendo a inovação. Um marketplace irá encorajar as organizações de saúde a pensar como podem expor os dados que possuem, fazendo com que os dados de saúde disponíveis sob iniciativas de APIs fiquem abertas.

Na prática, um API marketplace para a saúde, primeiramente irá conectar os dados de saúde dos consumidores com os produtores. A visão de solução é ter uma aplicação baseada de diversos marketplaces diferentes, criando uma economia baseada na troca de dados de saúde. A solução também discute uma gestão de API compreensiva, que alimenta o conceito do marketplace. A plataforma habilita a organização modelar, publicar e gerenciar as APIs, enquanto reforça a segurança, aplicando governança e coleta de dados.

A solução foca especificamente na capacidade de gerenciamento das APIs e trata alguns desafios sobre dados de saúde. Capacidades como o direito de acesso aos gateways pode prover garantias a organização que disponibiliza os dados, pois tem a certeza que a informação irão para o consumidor correto. Essas capacidades são discutidas amplamente sobre os tipos de API para o melhor contexto a serem utilizadas.

Figura 1: Solução Arquitetural

Elaborando a solução, nós podemos dar atenção aos envolvidos na TI na área da saúde. Existem engenheiros e gerentes de negócio responsáveis por plataformas que padronizam e gerenciam canais de dados. Existem stakeholders que produzem dados que precisam ser publicados, então também são partes interessadas. Existem stakeholders que constroem valor para o usuário final; esses stakeholders agregam múltiplas informações e oferecem produtos com estes dados. Existem usuários finais que consomem estas informações e através delas tiram conclusões e tomam decisões.

Stakeholders do API Marketplace

Figura 2: Análise dos Stakeholders

Os produtores das APIs possuem designers, arquitetos, desenvolvedores de produtos para a saúde e testadores, sendo este grupo responsável por definir o escopo da API (interno, externo, restrições e direitos). Em um grande sistema de trocas de APIs, os produtores podem ser de diferentes organizações de saúde.

Os donos das plataformas podem focar em um API Marketplace, mantendo os componentes e facilitando a colaboração entre as APIs dos consumidores e provendo um feedback para os provedores, tomando por responsabilidade a evangelização do uso da plataforma, o suporte e a construção da comunidade em torno das APIs.

Os consumidores das APIs são a comunidade de desenvolvimento de aplicações, são inovadores e estão dispostos a utilizar os dados de saúde e retirar valor, podendo ser a população criando iniciativas focadas na saúde e bem-estar, statups de saúde, organizações, grupos de hospitais e governos que querem conhecer e melhorar um cenário multifacetado dos dados de saúde.

Componentes de um Marketplace de APIs de saúde

Estes são os três aspectos para o sucesso de um Marketplace de APIs de saúde.

1. Gerenciamento de API
2. O Portal de desenvolvedores
3. Atividades

Figura 3: Componentes de um Marketplace de APIs

O gerenciamento de APIs é o principal parâmetro da plataforma e é responsável pelo cruzamento das informações dentro da arquitetura, encapsulando o gateway, a camada de segurança, de governança, de analytics e o de consentimento de uso.

O API Gateway atua como o ponto de entrada da plataforma, que conecta ao backend dos sistemas de saúde, integrando-se facilmente com a camada de segurança e faz uso de tokens e políticas de segurança.

Dada a natureza sensível dos dados expostos através das APIs, é crucial que o Marketplace de APIs possua uma forte governança sobre o desenvolvimento, publicação e manutenção do ciclo de vida das APIs. Controlando as características operacionais de como as APIs são expostas, os modelos de governança centrados nas pessoas, gestão de políticas e a análise de dependências devem ser mantidos através da camada de Governança das APIs

Após os desenvolvedores publicarem as APIs, devem ter a capacidade de monitorar, medir e gerenciar as APIs publicadas. Essa funcionalidade é disponibilizada pelo componente de analytics. Além de outras métricas, essa camada pode criar alertas, como por exemplo, na falha de comunicação da API, no aumento do tempo de resposta ou nos casos de troca no padrão dos recursos de acesso da API.

A camada de consentimento de uso de dados, implementa uma série de workflows que se fazem necessários para o compartilhamento de dados, armazenamento e consumo. Essa é uma política que é orientada às vezes por humanos e em outros momentos por sistemas.

O portal do desenvolvedor exibe as APIs para consumo, e instiga outros desenvolvedores a descobrirem os dados disponíveis e como consumi-los. O portal resolve o problema da visibilidade dos dados de saúde através das plataformas. Todos os sistemas especializados da área podem ter as APIs indexadas em um ponto central, mantido pelo provedor,seja ele uma organização, hospital ou serviço público.

Construir um bom Marketplace de APIs com componentes técnicos, é apenas uma parte de todo o processo. Além de construir um mercado de APIs de sucesso, os responsáveis pela plataforma devem engajar a plataforma através dos seguintes pontos:

• Workshops - Workshops provêem uma plataforma educacional para os consumidores das APIs, e podem tirar alguns bloqueios iniciais. Tópicos a serem incluídos, Como consumir dados dentro dos limites regulamentados da área médica? Que protocolos de segurança e políticas podemos implementar? Como gerenciar o consentimento de informações?
• Incentivar Hackatons - Um dos principais objetivos de construir um marketplace é disponibilidade a possibilidade de inovação na área da saúde. Incentivar hackatons é considerado um passo nessa direção. Os gerenciadores da plataforma devem organizá-los a fim de trazer à tona a geração de valor através dos dados de saúde;
• Evangelização - A evangelização interna e externa, para fazer a plataforma se tornar popular;
• Painéis de liderança e Dashboads analíticos - Exibir os casos de sucesso e inovadores, produtos de startups, e prover visibilidade para os padrões de uso de APIs.

Produtos de API de Saúde

As APIs no marketplace devem ser categorizada a partir dos produtos baseados no seu padrão de consumo. Na área da saúde, padrões comuns podem incluir o registro de pacientes, agendamento, finanças e cobrança, seguros, dados clínicos, auxiliares, saúde pública e IOT (Internet of Things).

APIs de Registros

As APIs de registros gerenciam as funções de registro envolvidas nos sistemas EMR. Por meio desse registro de APIs, os desenvolvedores podem ter a oportunidade de criar interfaces para desenvolver sistemas que integrem diferentes sistemas EMR, para gerenciar dados específicos dos pacientes. Autenticação e autorização são requisitos chaves dessas APIs, para a autorização das atividades subsequentes relacionadas ao consumo dos dados. A camada de gerenciamento das APIs do Marketplace pode prover pontos importantes de segurança para as atividades.

API de Agendamento

Fazer um agendamento, criar lembretes, verificar janelas de horários para agendamento, atualizar, cancelar ou reagendar são algumas das funcionalidades da API de agendamento. Agendamento é uma funcionalidade fortemente utilizada em um marketplace para saúde e integra vários sistemas, incluindo pagamento, troca de mensagens e notificações. O API Gateway, através da camada de integração, pode ser a ponte necessária entre esses sistemas para um agendamento eficaz pelo paciente.

API Financeira

As APIs financeiras irão gerenciar as transações envolvendo dinheiro entre as organizações de saúde e os respectivos parceiros. Estas APIs financeiras podem ser divididas em APIs de pagamentos, faturamento, declarações fiscais, etc. Os planos de saúde também são uma parte importante no processo financeiro das organizações. Os sistemas de solicitações facilitam a verificação de status, purificação das informações e concessão, assim como automação da postagem de pagamentos. Essa gestão de pedidos exposta em APIs habilita a conexão com os pagadores ao sistemas. A segurança é um dos requisitos críticos para essas APIs, onde o foco é ter uma autenticação muito forte. Ter uma plataforma de gerenciamento de API apropriada que possa interagir com provedores de identidade externos (IdPs) é necessária para suportar alguns desses requisitos.

API de dados Clínicos

As APIs de dados clínicos gerenciam a troca de dados através de sistemas EHR e EMR através de inúmeros padrões como HL7v2, HL7v3 e FHIR. uma plataforma de API madura tem capacidade de transformar as formatações dos dados, assim como conectar múltiplos sistemas e prover serviços de dados que podem ser solicitados pelos consumidores. Esses sistemas incluem fluxos de informação como medicamentos, planos de tratamento, imunização e histórico de saúde da família. O profissional de saúde utiliza esses dados para tomar decisões sobre a saúde do paciente. Através de um modelo baseado em API, com aplicações centradas no paciente, podem ter acesso a as medicações, diagnósticos e histórico médico dos usuários. Esse modelo encoraja os pacientes a se envolverem mais no processo de tratamento assim como as ações de saúde pública com o uso inteligente da informação.

APIs Auxiliares

As APIs auxiliares gerenciam as informações dos sistemas que não são o centro das funções clínicas, por exemplo os sistemas de farmácia, laboratório, radiologia, etc. Alguns exemplos são a comunicação com farmácias externas com prescrições médicas, troca de dados entre resultados de laboratório vindo de diferentes sistemas, gestão de planos para dieta enviados para sistemas externos de nutrição. Conectar com sistemas externos através de canais seguros (B2B) é um requisito crítico para essas APIs. Um gerenciador de APIs pode suportar diversos protocolos de segurança como OAuth2, SAML, OIDC, que facilitam uma conexão segura com os sistemas de terceiros.

APIs Públicas

Disponibilização de relatórios de saúde para o público, governo ou para profissionais utilizando as APIs públicas. Essas APIs habilitam a utilização de dados necessários para o monitoramento de saúde pública, provendo dados clínicos para o registro de dados de saúde nos EMRs para o governo e outras organizações de pesquisa e através da captura destes dados para enriquecimento dos dados clínicos locais.Estes dados devem ser transacionados utilizando padrões que garantem a privacidade das informações do paciente. Quando são providas essas informações , a API de comunicação pode remover os dados de identificação dos clientes e assim enviar de forma anônima. Essa é uma das muitas utilidades da API de comunicação.

IoT/Monitores de atividade API

Nos últimos anos houve um crescimento exponencial no uso de gadgets eletrônicos e monitores de atividade. Estes dados desbloqueiam uma nova dimensão no monitoramento pessoal de saúde, expondo estes dados através de uma plataforma que pode ser consumida, pode acelerar a criação de aplicações centradas no paciente.

Opções Tecnológicas

Na solução proposta, vemos a integração de sistemas e o gerenciamento de API como dois componentes de implementação distintos que exigem uma análise cuidadosa. Uma integração de componente deve preencher a necessidade de integrar diferentes sistemas de saúde sobre vários protocolos e modelos de mensagem. Em seguida, precisa converter e canonizar os dados fornecendo uma interface unificada.

A camada de integração deve limpar e anonimizar os dados, quando necessário, com base nas regulamentações. Existem várias soluções e tecnologias disponíveis para executar essa tarefa. Alguns dos principais produtos de código aberto são Apache Camel, Apache Synapse, Apache ServiceMix, Spring integration and Ballerina.

O componente de gestão de API é um grupo de funcionalidades, integrados a um gateway de alta performance, um servidor para autenticação, um gerenciador de eventos para controle de limite e análise, um portal de desenvolvedores e um sistema de workflow para gestão de consentimento para acesso aos dados. Algumas APIs open source encapsulam algumas funcionalidades com WSO2 API Manager, Kong API Gateway e Tyk API Gateway.

Referências de Implantação

Para uma prova de conceito, foi desenvolvido uma implementação de referência demonstrando as opções tecnológicas que podem ser utilizadas. Essa implementação está baseada em plataformas open source e ferramentas que oferecem uma grande flexibilidade de customização para o desenvolvimento da plataforma.

Figura 4: Implementação da arquitetura com as tecnologias selecionadas

Nessa implementação, o gerenciador de API endereça todo o ciclo de vida de gerenciamento de funcionalidades, incluindo a implementação, gerenciamento, monetização, segurança e roteamento de tráfego de APIs. A solicitação da API é exposta e é roteada para o componente de integração, por meio do gateway da API.

A implementação de referência leva em consideração o ciclo de vida da API, assim que uma API é publicada, a versão anterior deve ser reprovada e os assinantes devem ser notificados. A solução de gerenciamento de API lida com isso através de executores de ciclo de vida, portanto, cada estágio do ciclo de vida da API pode ser associado a uma ação a ser tomada, conforme mostrado na Figura 5.

Figura 5: Um exemplo de visualização do ciclo de vida da API

A segurança da API também é uma consideração de primeira instância. Embora a autenticação e a autorização sejam feitas por meio de tokens, as autorizações refinadas são aplicadas por meio dos escopos do token OAuth. Os escopos podem ser a validação de grupos de usuários ou um conjunto de atributos sobre o consumidor de dados de saúde, como um dispositivo, localização etc.

Figura 6: Um exemplo de aplicação de escopos OAuth de autorização para operações de API

A plataforma da API pode controlar como expõe os dados a terceiros, permitindo acesso ilimitado ou restrito por uma diretiva de limitação. O mecanismo de otimização da plataforma de gerenciamento de API define e impõe regras relativas ao número de solicitações permitidas e à taxa na qual os dados são consumidos

Figura 7: uma visão de exemplo de como as políticas de limitação são aplicadas às assinaturas de API

O portal do desenvolvedor de componentes fornece um hub central, no qual todas as APIs podem ser descobertas, testadas e inscritas. O portal do desenvolvedor fornece uma plataforma para inovação e documenta o que pode ser consumido de cada uma das APIs e como fazê-lo. O portal do desenvolvedor categoriza os produtos da API descritos neste artigo, permitindo que as partes interessadas assinem um produto e o integrem na aplicação.

Figura 8: Uma exemplo de um portal do desenvolvedor com APIs do paciente/provedor FHIR

A análise do gerenciador de APIs fornece uma visão de quais APIs são acessadas com mais frequência e como são usadas, fornecendo insights úteis para vários públicos-alvo. Para os mantenedores de plataforma, isso pode informar decisões relacionadas ao planejamento da capacidade técnica. Os consumidores das APIs querem entender a disponibilidade de dados de saúde e os provedores podem aprender onde explorar mais sobre as aquisições dos dados.

Figura 9: um exemplo de análises de APIs de saúde

Depois que a chamada da API delega a solicitação à camada de integração da solução, uma estrutura como Apache Synapse, Camel, Spring Integration ou Ballerina pode executar a funcionalidade de integração. Depois que a solicitação é recebida pela estrutura de integração, é verificada com uma entrada de registro local para identificar qual sistema de EHR o hospital pertence. Os valores podem ser armazenados como um campo texto, um código XML ou um URL. Isso também pode ser implementado como um arquivo ou uma consulta ao banco de dados.

Figura 10: Pesquisa do sistema a partir dos atributos do usuário

Uma vez marcada com a entrada local, a validação é realizada usando uma construção de filtro de mensagens para verificar se o nome do hospital está salvo na entrada do registro local. Se nenhum hospital for encontrado, uma mensagem de erro será enviada de volta à API como uma mensagem referente à indisponibilidade do hospital.

Figura 11: Processo de filtragem / validação

<inSequence>
<!--Obtain the value for the respected hospitalName parameter from the local registry-->
        <property expression="get-property($url:hospitalName)" name="ehrSystem" scope="default" type="STRING" xmlns:ns="http://org.apache.synapse/xsd"/>

<!--Check if the hospital-Name is located in the local registry entry-->
       <filter xpath="boolean(get-property('ehrSystem'))">
              <then>
              ...
	          </then>		 	 	 	
              <else>
                      <log description="Fault" level="custom" separator=",">
                               <property name="STATUS" value="Invoke fault "/>
                      </log>
                      <payloadFactory media-type="json">
                             <format>{ "Error":{      "errorType":"InvalidParameter","details":"The Hospital-Name parameter is invalid" } }
                             </format>
                             <args/>
                      </payloadFactory>
                      <property name="HTTP_SC" scope="axis2" type="STRING" value="400"/>
                      <respond/>
              </else>
     </filter>
</inSequence>

Bloco de Código 1: Validação do nome do hospital com Apache Synapse

A estrutura de integração usa um ou mais conectores para acessar dados de diferentes plataformas de EHR, permitindo que o usuário interaja com fornecedores de saúde de terceiros, como Epic, Cerner, etc. Com base no sistema EHR, o integrador determinará para onde rotear solicitação, chamando o conector Cerner ou o conector Epic para buscar dados do respectivo sistema EHR.

Figura 12: Encaminhando o pedido

A seguinte configuração de sinapse (XML) é usada para inicializar os conectores Epic e Cerner e buscar os dados do relatório de diagnóstico.

<switch source="$ctx:ehrSystem">
<case regex="Cerner">
	<!--Initialize the Cerner Connector-->	 	 	
<cerner.init>
<base>https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca</base>
</cerner.init>

<!--Search DiagnosticReport Operation→
<cerner.searchDiagnosticReport>
		<patient>{$ctx:patient}</patient>
<subject>{$ctx:subject}</subject>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
<count>{$ctx:count}</count>
</cerner.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<case regex="Epic">
<!--Initialize the Epic Connector--> 	 	 	
<epic.init>
		<base>https://open-ic.epic.com/FHIR/api/FHIR/DSTU2</base>
</epic.init>

<!--Search DiagnosticReport Operation→
<epic.searchDiagnosticReport>
		<id>{$ctx:id}</id>
<patient>{$ctx:patient}</patient>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
</epic.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<default/>
</switch>

Bloco de Código 2: Roteando para o sistema específico de EHR com Apache Synapse

A resposta recuperada com base no sistema EHR é enviada para a API como uma resposta por meio do API Gateway.

Sobre os autores

A implementação de referência que discutimos na seção anterior considerou um cenário simples para mostrar o uso prático de um mercado de API de dados de saúde. Esta implementação pode ser melhorada para suportar uma ampla gama de requisitos no setor de saúde, incluindo:

• Integração com dispositivos pessoais de saúde digital
• Conectando-se com provedores de serviços de saúde de terceiros
• Construindo aplicativos móveis centrados no paciente
• Conectando-se com institutos de pesquisa em saúde para fornecer dados valiosos

À medida que os serviços de assistência à saúde e a tecnologia evoluem, os mercados de API de produtos de saúde desempenharão um papel de liderança no setor de assistência médica digital.

About the Authors

Nuwan Bandara é um arquiteto de soluções que trabalha em colaboração com empresas globais da Fortune 1000 em projetos de software de integração e mensagens. Ele é diretor da WSO2 e lidera equipes de engenharia de soluções na América do Norte. Nuwan trabalhou em projetos interessantes nos setores de saúde, governo e financeiro para simplificar a integração de sistemas. Ele é programador, palestrante e autor.

Chanaka Fernando é arquiteto de soluções na WSO2. Trabalha com clientes corporativos em vários domínios, como financeiro, educação, saúde e telecomunicações, para citar alguns. Ele trabalhou como líder técnico e líder de produto na plataforma de integração da WSO2 ao longo de sua carreira.

Sachini Samson é estudante do terceiro ano de engenharia de software no Instituto de Tecnologia de Informática do Sri Lanka e atualmente está cursando o estágio de engenharia de software da WSO2. Samson é a principal desenvolvedora da implementação de referência da solução discutida neste artigo.