Defining an open Platforms

“O que são as Plataformas Abertas”

Há bons anos acompanho e participo de grupos de discussão e de trabalho sobre como as plataformas em saúde devem ser construídas não só em seus aspectos técnicos, mas em especial, aos conceituais e os leitores dos artigos da InterOpera sabem que somos uma organização adepta e entusiasta de novas tecnologias e em especial das plataformas abertas.

Em 31 de outubro de 1517 se iniciava a Reforma Protestante onde Martin Luther (monge agostiniano) pregava pelas portas das igrejas do Castelo e de Wittenberg, sua proposta de reforma, que não tinha intenção de ser um ato de provocação ou desafio, mais conhecida como as 95 teses, onde debatia sobre a doutrina e a prática de indulgências.

500 anos após, em 31 de outubro de 2017, a Fundação Apperta publica o documento “Defining an Open Platform” em que apresenta oito princípios importantes para a Reforma na Saúde Digital, para que esta permita que a tecnologia digital tenha o esperado efeito transformador em nosso setor, o que até agora nos tem iludido.

Como uma organização adepta e entusiasta de novas tecnologias e em especial das plataformas abertas, estamos bastante empolgados com o trabalho conduzido pela Fundação Apperta e com a recente publicação do documento “Defining an Open Platform”, originalmente em inglês.

Leitores mais assíduo de nossos artigos poderão perceber que os oito princípios deste documento são uma evolução dos oito princípios elencados na publicação ‘DEFINING AN OPEN PLATFORM’ do Ewan, da Woodcote Consulting, de março de 2016.

Acredito que a definição para “plataforma aberta” deixa claro que estas são agnósticas no que se diz respeito ao licenciamento do software e dos direitos de propriedade intelectual.

No entanto, há dúvidas, as pessoas se confundem sobre o que são plataformas abertas com opensource. Vejamos:

Primeiro vou mencionar os autores, que acumulam uma ampla gama de experiências clínicas em informática em saúde e em economia, nos sistema de saúde do Reino Unido:

Ewan Davis – Woodcote Consulting
Dr Tony Shannon – Ripple Foundation
Dr. Ian McNicoll – Fundação OpenEHR
Dr. Roland Appel – Maycroft Consulting
Silas Davis – Monax
Dr. Rebecca Wassall – Fundação Apperta
Peter Coates – NHS Digital Code4Health

Prefere ler o artigo em PDF?

Clique Aqui

As plataformas abertas são sobre padrões abertos mas não requerem software de código aberto.

Uma plataforma aberta pode ser criada sem uma única linha de código aberto ou, de fato, sem uma única linha de código proprietário, isto depende do desejo dos envolvidos em sua construção, embora na prática, nenhuma dessas escolhas seja provável ou desejável, mas ambas são possíveis.

As plataformas abertas são sobre padrões e embora esses padrões geralmente sejam, mas nem sempre ” abertos”, o software que os implementa, não necessariamente precisa o ser.

O princípio central de uma plataforma aberta é que o acesso aos dados e aos serviços desta plataforma sejam através de um conjunto de APIs abertas que aceitem e retornem dados em formato aberto, compartilhável e processável por computador (computável).

As definições destes conjuntos de APIs precisam serem abertas para que assim qualquer parte interessada possa implementá-las livremente e enquanto seus membros (da plataforma aberta) estiverem de acordo com estas APIs, tanto as aplicações como os dados são portáteis e o ‘bloqueio’ do fornecedor não é mais uma barreira, e isto, independente de (s) componente (s) e aplicativo (s) serem de código aberto ou proprietário.

Atualmente a maioria das implementações em grande escala de plataformas abertas (por exemplo, em Moscou) consistem principalmente de aplicativos proprietários que funcionam sobre uma plataforma proprietária.

Moscou utiliza a plataforma Marand openEHR Clinical Data Repository e o Forcare Implementation of IHE-XDS, sendo ambas, implementações proprietárias de padrões abertos.

Um dos pontos chave é que Moscou pode trocar os produtos proprietários por outras alternativas se um fornecedor não entregar desempenho ou o valor esperado.

Existem outras alternativas de código aberto para estes e outros produtos proprietários, mas a existência destes é importante para garantir que os fornecedores proprietários permaneçam fiéis aos padrões.

Também é verdade que as implementações proprietárias muitas vezes contêm componentes de código aberto (muitos dos quais provêm destes mesmos fornecedores proprietários que são sábios em compartilhar e abrir determinados componentes).

A expectativa é que os ecossistemas bem sucedidos sobre plataformas abertas sejam um mix de componentes e aplicações abertas e proprietárias.

Penso que surgirão mais modelos economicamente sustentáveis de código aberto em relação aos componentes de infraestrutura da plataforma e menos para as aplicações.

PLATAFORMAS ABERTAS – OPEN PLATFORMS

É amplamente aceito que o futuro da saúde digital está nas “Plataformas Abertas”. No entanto, não está claro o que é uma plataforma aberta ou a forma como chegaremos lá. Esta é uma questão a ser respondida com urgência.

Segundo a organização McKinsey&Company, os sistemas em saúde que utilizam uma plataforma aberta têm uma economia de mais de 11% sobre o custo total dos cuidados em saúde.

“……. Todo sistema de saúde local, regional ou federal deve considerar o uso de uma plataforma de inovação aberta que armazene e disponibilize dados eletrônicos de saúde ……………., Deve fornecer acesso a estes dados através de APIs (interfaces de programação de aplicativos), bem como serviços técnicos de TI genéricos como gerenciamento de identidade, acesso e consentimento. Esta plataforma servirá de base para um ecossistema de inovações para os serviços em saúde digital …… “

“Em 2014, fizemos pesquisas consideráveis sobre o valor econômico das tecnologias digitais em saúde e descobrimos que …… Os benefícios econômicos líquidos estão entre 7 e 11% sobre os gastos totais com saúde. Durante o ano passado, nosso trabalho nesta área confirmou esta análise. No entanto, acreditamos que um impacto ainda maior possa ser alcançado através de esforços coordenados em conjunto. Isso envolveria a interconexão de todas as partes interessadas em saúde digital através de uma plataforma aberta de inovação “.

Confira: McKinsey and Co. – Janeiro de 2016

Embora qualquer instância de uma plataforma aberta seja a implementação específica de um conjunto de componentes de software de propriedade e operação de determinada organização (uma organização de saúde ou um terceiro que opera a plataforma em nome de uma comunidade local), esta será mais útil se implementando um conjunto de princípios ao invés de detalhes específicos de implementação.

Princípios para as Open Platform – Plataforma Aberta

Qualquer implementação de uma plataforma que esteja comprometida verdadeiramente em atender à definição de “aberta/open”, deve respeitar aos seguintes princípios:

Ser Open Standard Based – A implementação é baseada em padrões abertos para que qualquer parte disposta possa utiliza-la gratuitamente para construir uma instância Open Platform – estes padrões serão descritos mais adiante neste artigo.

Compartilhar modelos de informações comuns – Deve haver um conjunto de modelos de informações comuns usados por todas as instâncias da plataforma aberta, independente dos detalhes técnicos sobre sua implementação.

Suporte a portabilidade de aplicativos – Aplicativos escritos para serem executados em uma implementação podem ser executados com pouca ou nenhuma alteração em outra implementação desenvolvida de forma independente.

Ser Federado – Qualquer implementação de Plataforma Aberta pode ser conectada com todas as outras implementações independentemente se desenvolvidas em uma estrutura federada permitindo o compartilhamento de informações e fluxos de trabalho apropriados entre estas.

Vendor and Technology Neutral – Os profissionais que criam a implementação para uma Plataforma Aberta podem optar por tecnologias específicas e ou por usar e incluir componentes proprietários, mas os padrões a serem implementados não devem depender destas tecnologias específicas ou exigir componentes de fornecedores específicos.

Suporte a Dados Abertos (Open Data) – Uma plataforma aberta pode expor os dados que contém em formato aberto, compartilhável e computável em tempo quase real;

- Aqui os implementadores devem decidir se optam por usar este modelo de forma nativa em sua camada de persistência (armazenamento), ou se atenderão a este requisito por meio de mapeamentos e transformações a partir de algum outro formato de dado aberto ou proprietário.

Fornecer APIs abertas – As APIs são o meio pelo qual os aplicativos conectados à Open Platform acessam e atualizam os dados que ela contém. Há uma série de APIs abertas disponíveis (veja abaixo) e, idealmente, qualquer plataforma deve suportar uma série destas para oferecer a máxima flexibilidade aos aplicativos que desejam se conectar a ela.

Padrões para as Plataformas Abertas

Para atender a estas características, isto implicará no uso de determinadas abordagens e na adoção de certos padrões. No entanto, é importante entender que por sua própria natureza, uma plataforma aberta, assim como a Internet, não é algo que possa ser rigidamente definida e, de fato, é algo que evolui continuamente.

Existem diferentes maneiras de se construir uma plataforma aberta e para que estas trabalhem juntas, e por não podemos manter uma padronização rigorosa, é necessário que utilizemos uma abordagem em comum consenso para que tudo funcione.

Essa abordagem precisa ser diferente da que historicamente foi adotada por instituições como o NHS IT, devendo ser o mais próximo do modelo em que a Internet e a World Wide Web foram construídas. Você pode ler mais sobre o assunto nestes dois artigos: Farewell to “Ruthless Standardisation”, de setembro de 2014 e neste de novembro de 2014, Let’s do it Like the Internet, ambos do site da Woodcote.

O núcleo de uma plataforma aberta tem como necessidade, modelos de informações comuns, que definam o conteúdo clínico (a informação) para serem representados pela plataforma e que permitam um formato compartilhável, aberto e computável para a informação. Podemos citar abordagens como Clinical Element Models (CEMs) e o openEHR, que tem apoio e o suporte da comunidade global de informática em saúde.

Ambos têm abordagens semelhantes e são coordenadas através de iniciativas do CIMI. No NHS, o HSCIC escolheu usar o openEHR porque é um modelo que está tendo aceitação e uso globalmente difundido.

Os modelos de informação, como os criados pelo openEHR, podem ser usados de forma nativa pelos componentes de persistência (armazenamento) e pelos componentes de mensagens da plataforma, ou usados simplesmente no projeto desses componentes aplicando qualquer outro padrão aberto, como HL7 FHIR , XML, JSON , ou abordagens proprietárias.

O ponto crítico é que uma plataforma aberta produz e consume dados conforme o modelo de informação implementado. Esta é uma tarefa é para os designers de plataformas que devem decidir sobre como resolver isto, mas o esperado, é que as criem do zero, usando o openEHR nativamente na camada de persistência, e também por todos aqueles que forem adaptar seus sistemas existentes para convergirem para estes padrões ao longo do tempo.

Arquitetura – Plataformas Abertas

A arquitetura de uma plataforma aberta evolui ao longo do tempo e é provável que diferentes implementações da plataforma variem em detalhes de sua arquitetura e em componentes específicos.

O menos importante é que as implementações sejam idênticas, e o mais importante é que respeitem os princípios descritos acima. O diagrama abaixo propõe uma possível arquitetura. Qualquer plataforma aberta desse tipo provavelmente terá componentes semelhantes, dispostos em uma arquitetura funcionalmente equivalente e implementando um conjunto semelhante de padrões.

Imagem: Woodcote

O núcleo da plataforma é um Enterprise Service Bus ( ESB ) que conecta os componentes e fornece autenticação agregando o gerenciamento das Interfaces de Programação de Aplicativos (APIs) que servem tanto como componentes da plataforma e serviços para que os sistemas externos se conectem à plataforma.

Os principais componentes:

Repositórios para dados estruturados e não estruturados (documentos, imagens, etc.);
Índice Mestre de Pacientes (MPI) e Registro que armazene dados demográficos básicos e forneça um serviço localizador para ajudar a encontrar onde os registros de um paciente específico são mantidos
Serviços de apoio a decisão que proporcionem acesso ao conhecimento (particularmente fluxos de trabalho, processos e suporte à decisão);
Variedade de conectores externos que permitam que aplicativos da plataforma se conectem a sistemas existentes e relevantes para a comunidade local de saúde, incluindo outros sistemas locais e serviços nacionais (ex: NHS Spine);
Gama de serviços de plataforma, sendo que nenhum dos quais é essencial, mas que se disponível remova o ônus de se ter que lidar com funções de apoio que estes proporcionam aos desenvolvedores de aplicativos. Estes podem ser:
- Serviços de terminologia;
- Gerenciamento de identidade;
- Gestão de consentimentos; e,
- Controle de acesso (regras baseadas em acesso (RBAC), relacionamentos legítimos (LRs) e em grupos de trabalho.
Conectores e serviços de federação para outras plataformas, permitindo que estas se conectem através de uma Web federada, facilitando ao usuário autorizado, localizar e acessar dados relevantes em qualquer local.

Muitos profissionais em informática em saúde tem a mesma e forte opinião de que a escolha certa para um repositório de dados estruturados é openEHR e a escolha certa para o armazenamento de dados não estruturados é o IHE-XDS.

Ambos são padrões abertos e suportados pelos fornecedores através de diversas implementações comprovadas e opções para código aberto emergentes. No entanto, existem outras abordagens que podem cumprir os princípios descritos acima.

Com relação à melhor abordagem para o repositório de conhecimento, existe um trabalho da Synapta que reúne um conjunto de outros padrões como: BPMN 2.0 , GDL , CMMN , Drools e PROforma e que parece ser promissor.

Exemplos de Plataformas Abertas

Há uma série de exemplos de plataformas abertas que aderem aos princípios aqui descritos e um número grande de pessoas trabalhando para criarem outras.

Uma das plataformas que implementam tanto o openEHR como o IHE-XDS, e que trabalham em conjunto, está operando em Moscou e suportando dados de saúde e de assistência social de 12 milhões de pacientes e na Eslovênia que suporta e apoia a uma população total de 2 milhões.

Existem outros exemplos baseados em um ou outro desses padrões que podem ser facilmente estendidos para se fazer o mesmo ocorrendo no Reino Unido.

Podemos citar alguns destes projetos que estão atuando em refinar esta definição para plataforma aberta e também criar implementações para elas:

NHS England Code4Health: A plataforma Code4Health fornece um ambiente simulado onde as pessoas podem explorar conceitos sobre plataforma aberta e APIs e ainda criar aplicativos para testar suas ideias.
Ripple: plataforma operacional aberta baseada em openEHR.
O Endeavor Health Charityque está construindo uma plataforma usando o HL7 FHIR e um conjunto de conectores para sistemas legados.
Operonestá desenvolvendo o Synapta para fornecer componentes para suportar padrões de fluxo de trabalho aberto, como BPMN 2.0 , GDL , CMMN , Drools e PROforma

Estes projetos atuam em conjunto e são coordenados pela Apperta (uma empresa sem fins lucrativos que é liderada por clínicos com auxílio da NHS England). Eles estão empenhados em usar um conjunto comum de modelos de informações usando as ferramentas openEHR.

O objetivo é concordar com um conjunto comum de padrões e componentes que lhes permitirá construir implementações de plataformas abertas que cumpram com os princípios apresentados aqui.

Cada implementação será diferente para permitir aprender sobre o que funciona melhor mas o suficiente para habilitar a federação e a interoperabilidade.

Estamos acompanhando uma série de projetos em pipeline e outros projetos existentes que já estão usando um ou mais dos principais padrões descritos aqui não só com openEHR mas muitos com HL7 FHIR.

Esperamos ver muitas plataformas abertas que cumpram com os princípios aqui descritos.

PLATAFORMAS LIVRES

Como não há uma definição formal para plataformas abertas (open) podemos encontrar outras definições e opiniões sobre o tema onde destacamos complementarmente as Plataformas Livres.

Quanto a nomenclatura, esta, quando utilizada com o termo open (abertas) pode soar erroneamente pela extensa ambiguidade da palavra em inglês ‘open’ ou ‘aberta’, em português-br. Desta forma, emprestou-se o termo ‘Libre’, que vem do francês e traduz-se por “Livre”.

Uma plataforma ‘livre’ significa que o usuário tem toda a liberdade de utilizá-la como desejar, sem restrições e para qualquer finalidade. Muitas vezes será de código aberto, mas isto não é um requisito.

Para que uma plataforma seja usada abertamente, ela deve expor as interfaces de programação de aplicativos (APIs) que fornecem as funcionalidades que os desenvolvedores de software precisam para construir aplicações sem restrições, e quando estas APIs aderem a padrões abertos aceitos, estas, tornam as aplicações portáteis entre diferentes instâncias da plataforma.

Dito isto, duas plataformas que oferecem as mesmas APIs não precisam ter estruturas internas idênticas, desde que elas se pareçam iguais e se comportem da mesma maneira externamente.

Internamente, o fornecedor pode implementar a plataforma da maneira que desejar, sem referência a nenhum padrão, aberto ou não. Da mesma forma, se a informação que é apresentada através de uma API está estruturada corretamente e é logicamente consistente, o modelo de informação interno será pouco relevante.

Dentre os oito princípios sugeridos para as plataformas abertas está que elas devem ser “federeratable ” (federadas). Este é um bom conceito e uma característica desejável, mas não pode ser considerado como requisito para que uma plataforma seja aberta.

Uma plataforma aberta que não ‘fala’ com seus vizinhos não é reflexo de restrições à sua abertura e nem impede que o uso de seus serviços seja livre.

Alguns pontos em comuns e em particular, é que toda plataforma aberta tem que oferecer APIs abertas, e os aplicativos escritos para uma implementação de plataforma, devem ser facilmente portáveis para outras implementações.

O openEHR se encaixa nesta definição de plataforma aberta. No entanto, existem outras plataformas de informações de saúde que fornecem APIs abertas e toda a liberdade para usar a plataforma sem restrições sendo estas também abertas.

Trataremos destas plataformas em nosso segundo artigo, onde abordaremos as plataformas HL7 FHIR, que estão sendo amplamente desenvolvidas e adotadas.

As considerações mais importantes sobre plataformas, é que uma plataforma é escalável, robusta, deve suportar o modelo de dados e de informação definidos e permitir que se criem aplicações, soluções ou produtos aproveitando das APIs abertas implementadas pela plataforma.

Sendo assim, promovesse um ecossistema que permite a uma comunidade construir sobre esta plataforma aberta, desenvolver novas funcionalidades e/ou aprimorar as já existentes.

E você… Como define uma plataforma? Aberta? …. Livre?

Referências:

Woodcote, http://www.woodcote-consulting.com/reformation/
IT’S NOT ABOUT OPEN SOURCE, http://www.woodcote-consulting.com/its-not-about-open-source/
OPEN DIGITAL PLATFORM CHALLENGE FUND, http://www.woodcote-consulting.com/open-digital-platform-challenge-fund/
Dia da Reforma Protestante, https://pt.wikipedia.org/wiki/Dia_da_Reforma_Protestante
Defining an Open Digital Platform , https://apperta.org/openplatforms
The open e-health platform, coming to an economy near you, https://wolandscat.net/2017/11/18/the-open-e-health-platform-coming-to-an-economy-near-you/#more-1160

CURSO ON-LINE AO VIVO: HL7 FHIR – ESPECIFICAÇÃO E IMPLEMENTAÇÃO

CURSO ON-LINE AO VIVO: HL7 V2 – HANDS-ON FAST TRACK

Leia também o artigo original da Apperta, existem muitas informações.

Contribua com seus comentários!

Download: Apperta – Defining_an_Open_Platform