v

Acknowledgments

First of all, a special acknowledgement to my parents for always supporting me on these crazy choicesof going abroad to experience new cultures and methods of study or work, for showing me the right wayto follow and for teaching me how to not lose hope and always fight for what I want.

To Samuel Frade, my co-advisor, for all the patience to introduce me to the openEHR world in adetailed way and giving me the idea of this dissertation theme to work in. And for answering my never-ending calls asking for help with Marand tools. And for all the guidance, support and commitmentprovided on this work.

To Tina Vavpotic for the constant trust, support, listening, eternal patience and resilience during allthe year not letting me give up. Sometimes living alone in another country can be hard. And also, forthe chance to work on Pathfinder.

To Leandro Gomes, also for the patience and willingness for teaching me how to solve the various bugsthat appeared on my script (on a Slovenian keyboard without some special characters, which made thistask 10 times worse), since programming on web development with languages like Angular was prettynew for me.

To Ales Cerne and Marko Pipan for the really useful advice and insight about openEHR resourcesand for teaching me how to deal internally with ADL Designer. To Metod Ribic and Marcel Salej for,once again, helping me to deal with some issues in the script.

To my advisor, Ricardo Correia for the encouragement and advices given to go abroad on this adven-ture and learning more about medical informatics in a practical way.

To all the people that work at Think!Registry team at Marand, I have learned a lot with all of you.To Cristina Castro Ribeiro, ECIM course director, for the trust, introduction on the Erasmus pro-

gramme, advices and concern during all these six years of academic life.And at last, but not least, to all the ECIM and Biomedical Engineering praxis group at ISEP for

the friendship, for showing me the values of a group that fights for a reason and for giving me the bestmoments of my academic life. And for always having their “arms wide open” ready for a huge welcominghug every time I was going back to Portugal.

A big, big thank you to all. Without all of you this would not be possible.

vi

vii

Abstract

The openEHR is a free open-source standard which provides specifications on how to store, share andretrieve health data with the main idea of separating this data from the applications implementationlogic, as an agnostic approach. It has its own governance library repository of resources (archetypesand templates) called Clinical Knowledge Manager (CKM), that is under constant review by an onlinecommunity of health care and informatics experts. However, there is an emerging issue. Each companyor institution working with openEHR archetypes and templates for their projects, have their own localrepository in a file system or a Control Version System (CVS) to manage them. These local repositoriesare usually created at the start of a project by downloading copies of the available archetypes from theCKM at a certain point in time and usually these are not kept updated. Over the years, the main CKM(also known as International openEHR CKM) keeps updating versions for the different archetypes, havinga very well-structured management of the archetype’s lifecycles, with the new version being approvedafter a community consensus (Leslie, 2017). This implies that knowledge in the openEHR CKM staysalways updated, but that does not necessarily happen on the local repositories.

Until now, there was no clear definition on how to solve this issue: how to manage a local repository,keep it connected to the CKM and maintain the local repository updated and compliant with it. Basedon this problem, the aim of the study was to find and implement a suitable way of having the differentopenEHR local repositories updated and compliant with the international openEHR CKM. In order toachieve it, studies were made, such as:

1. Learn how the openEHR CKM works, history, features, functionalities and how the verification ofnew versions of artifacts is made;

2. Study state of art methodologies used for managing software and document lifecycles;3. Review of the openEHR specifications, Reference Model (RM) and Archetype Model (AM), for

related with archetype identification and versioning;4. Creation of documentation about how to deal with archetype versioning on a local repository and

a script to compare the artifacts content in both repositories and verify new updates for eacharchetype from openEHR CKM;

5. Development and implementation of the proposed methodology and verification of results.

Initially a comparison analysis was made between archetypes stored in a local repository of an ongoingproject and the current version of the same archetypes in the international openEHR CKM, whichconsisted on a direct comparison between the major version (V.x), versioning parameters and the contentof these archetypes. From this repository, 1

4 of the total archetypes (n=41) were outdated. Having arepository with these characteristics is not the aim of openEHR ideals. This local repository for testing

viii

was provided and the openEHR CKM mirror is publicly available on GitHub. The tools used werecomposed by ”ADL Designer” version 2 from Marand, GitHub REST API, GitLab REST API, openEHRCKM and Tortoise SVN. The script for comparing both repositories was programmed on Angular 2 andTypescript using REST API calls from ADL Designer and GitHub API.

The gathering of all the information from this study, allowed to create a methodology and a script forversion comparison, along with documentation of how to deal with the versioning of openEHR archetypeson new and ongoing projects of local repositories. It is expected to contribute with an added value tothe governance of openEHR resources. The study was made along with the Faculty of Medicine of PortoUniversity in Portugal and the private company Marand d.o.o in Slovenia, under the Erasmus + intern-ships mobility from September 2017 to September 2018.

Keywords: (MeSH) Electronic Health Records, Medical Informatics, Health Information Exchange,Health Information Management, (Non-MeSH) OpenEHR, Version Control

ix

Resumo

O openEHR é uma norma de especificação aberta e livre que providencia como guardar, partilhare retornar dados de saúde, com a principal ideia de separar estes dados da implementação lógica dasaplicações, de uma forma agnóstica. Possui o seu próprio repositório de governância de recursos ouartefactos (arquétipos e templates) chamada Clinical Knowledge Manager (CKM), que está sob constanterevisão por uma comunidade online de profissionais em cuidados de saúde e informática. Apesar disso,existe um problema emergente. Cada empresa ou instituição que usa os arquétipos e templates doopenEHR nos seus projectos, possuem o seu próprio repositório local com um sistema de ficheiros ousistema de controlo de versões para os gerir. Estes repositórios são criados no início do projecto, através dodownload de cópias dos arquétipos disponíveis na CKM num determinado período de tempo e usualmentenão são mais actualizados. Durante os anos, a CKM principal (também conhecida como openEHR CKMInternacional) teve nova versões actualizadas para diferentes arquétipos, tendo também uma gestão bemestruturada dos ciclos de vida dos arquétipos, com as novas versões a serem aprovadas depois do consensode membros da comunidade (Leslie, 2017). Isto implica que o conhecimento da openEHR CKM estásempre actualizado, mas isso não acontece necessariamente nos repositórios locais.

Até agora, não havia uma definição clara de como resolver este problema: como gerir um repositóriolocal, mantê-lo conectado com a CKM e manter o repositório local actualizado e em conformidade comeste. Baseado neste problema, o objectivo do estudo foi encontrar e implementar uma forma adequadade ter diferente repositórios locais baseados em artefactos do openEHR actualizados e em conformidadecom o repositório do openEHR CKM internacional. De modo a alcançar este objectivo, vários estudosforam feitos, tais como:

1. Estudar como a openEHR CKM funciona, historia, características, funcionalidades e como a veri-ficação de novas versões é feita;

2. Estudar o estado da arte de metodologias usadas para gerir software e documentação de ciclos devida;

3. Rever as especificações do openEHR para o Modelo de Referência (RM) e Modelo de Arquétipos(AM), relacionado com a identificação e versionamento de arquétipos;

4. Criação de documentação sobre como lidar com o versionamento de arquétipos num repositóriolocal e de um “script” para comparar os arquétipos contidos em ambos os repositórios e verificar asnovas versões para cada arquétipo da openEHR CKM no GitHub.

5. Desenvolvimento e implementação da metodologia proposta e verificação de resultados.

Inicialmente foi feita uma análise através da comparação entre arquétipos guardados num repositóriolocal de um projecto em desenvolvimento e da versão actual do mesmo arquétipo na openEHR interna-

x

cional, a qual consistiu numa comparação directa entre a versão “major” (V.x, onde x é um número inteirocorrespondente à versão), parâmetros de versionamento e o conteúdo dos arquétipos. Deste repositório,14 do número total de arquétipos (n=41) estão desactualizados e ter um repositório com estas caracter-isticas não é o objectivo dos ideais da norma openEHR. Este repositório local para testes foi fornecidoe o conteúdo da openEHR CKM é replicado para um repositório de uma conta pública hospedada noGitHub, denominada “OpenEHR CKM international Mirror”. As ferramentas usadas foram compostaspor: “ADL Designer” na sua segunda versão criada pela Marand, REST API do GitHub e do GitLab,openEHR CKM and Tortoise SVN. O script criado para a comparação de ambos os repositórios foibaseado em Angular 2 e TypeScript, e foram usadas chamadas e métodos para as REST API do ADLDesigner e GitHub.

A junção de toda a informação recolhida neste estudo permitiu criar uma metodologia e script paracomparação de versões, juntamente com documentação sobre como lidar com o versionamento dos ar-quétipos do openEHR em projectos novos ou em desenvolvimento em repositórios locais. É expectávelque contribua com um valor acrescido para a governância de recursos do openEHR. Este estudo foi feitojuntamente com a Faculdade de Medicina da Universidade do Porto (FMUP) em Portugal e a Marandd.o.o. na Eslovénia no âmbito do projeto em mobilidade “Erasmus + Estágios” de setembro de 2017 asetembro de 2018.

Palavras-chave: (MeSH) Electronic Health Records, Medical Informatics, Health Information Ex-change, Health Information Management, (Não-MeSH) OpenEHR, Version Control

xi

Preamble

Nowadays, it is almost impossible for the population to image themselves without any technologyto help on their daily basic routines or even to take care of their health. Since an early age, I had ahuge interest in the electronic mechanisms in the medical area, mainly because these were so impor-tant to support my own life when I was a newborn. With that, I decided to do a licentiate degree inMedical Computing and Instrumentation Engineering (ECIM) at Engineering Institute of Polytechnic ofPorto (ISEP). The interest in information technology associated to the medical field started to appearfrom the previous course and in 2017 I decided to start my master studies in the Master in MedicalInformatics (MIM) at Faculty of Medicine of the University of Porto (FMUP) and Faculty of Science ofthe University of Porto (FCUP). Also, I had the opportunity to work as a junior student researcher inCenter for Research in Health Technologies and Information Systems (CINTESIS) and at Healthy Sys-tems, a spin-off company from University of Porto focused on cybersecurity and performance consultingin healthcare systems. From there onward, I developed an interest in the standards of medical data andinteroperability between different systems, mostly due to the opportunity of checking how it works in thereal-world during this professional experience.

As an user with slightly preference on free open-source systems, I always had the idea that informationand technology should be free and available to everyone. Once, I had the chance to listen a presentationabout openEHR and the curiosity on this topic increased even more. So I planned to do a future studyin this area and learn more about it. After some research on the actual market, I decided that themost advantageous option was to do again a mobility programme, now during the master degree underErasmus + internship. After applying, there was the possibility of making the dissertation at Marandd.o.o., a healthcare IT company located in Ljubljana, Slovenia, that mostly makes use of OpenEHRstandard on their electronic health record systems (EHR). Along the academic year of 2017/2018, I havebeen working as an analyst/consultant for one of the projects inside of Marand, the Advanced CongestiveHeart Failure (ACHF) where I have been doing several tasks, such as functional analysis, openEHRmodeler, terminologies definer and functional tester for the web portal of the project.

”Every path is the right path.Everything could’ve been anything else.

And it would have just as much meaning.”� from Mr. Nobody (2009)

xii

xiii

Scientific and Financial Results

Submitted and accepted articles:

• Pereira, V., Frade, S., Gomes, L., Vavpotic, T. and Cruz-Correia, R (2018) Governance of openEHRbased local repository compliant with openEHR Clinical Knowledge Manager. Journal of Health Informatics(J. Health Inform). CBIS 2018 - XVI Congresso Brasileiro de Informática em Saúde.

Open-source contributions:Script for governance of openEHR based local repository compliant with openEHR Clinical Knowledge

Manager:

• Code: https://github.com/vanessa-pereira/openEHR_compliance_script

• Live Demo: https://mim-script-openehr.stackblitz.io

xiv

xv

Table of Contents

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiResumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPreamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiScientific and Financial Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xixList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiAcronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Electronic health record (EHR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.3 Healthcare data standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.3.1 Content standards: Health Level 7 (HL7 v2) and HL7 CDA . . . . . . . 61.1.3.2 Data Exchange / Transport: HL7, FHIR, IHE. DICOM and PACS . . . 81.1.3.3 Terminologies, classifications and nomenclatures: ICD, SNOMED, LOINC,

MeSH, UMLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.3.4 Information Modelling: HL7 RIM and openEHR . . . . . . . . . . . . . 14

1.2 Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.1 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 OpenEHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3.2 Two level modeling (RM and AM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3.3 CKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3.4 Clinical Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3.5 Archetypes, Templates, ADL and AQL . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.3.5.1 Understanding the archetypes . . . . . . . . . . . . . . . . . . . . . . . . 251.3.5.2 Archetype specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3.5.3 Understanding the templates . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3.6 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.4 Life cycles of projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

xvi

1.5 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.5.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.5.2 Version Control Systems (VCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.5.3 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.5.3.1 GitHub and GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.5.4 Semantic Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Study I - openEHR CKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1 Instances of CKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3 Features and functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4 Management of artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5 Identifying parameters of new versions of archetypes . . . . . . . . . . . . . . . . . . . . . 47

3.5.1 The Archetype Object Model (AOM) . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.1.1 Version numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.5.1.2 Versioning parameters inside of ADL files . . . . . . . . . . . . . . . . . . 51

3.6 Current outcomes from openEHR artifacts usage . . . . . . . . . . . . . . . . . . . . . . . 543.7 Structure of openEHR Foundation International CKM Mirror on GitHub . . . . . . . . . 54

4 Study II - Life cycles of archetypes and templates . . . . . . . . . . . . . . . . . . . . . 594.1 The Archetype Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Distributed governance of archetypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3 Governance of a local repository based on openEHR artifacts . . . . . . . . . . . . . . . . 66

5 Material and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1 Analysis of archetype content from local repository and comparison with openEHR CKM

repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.1 Other Findings between analyzed repositories . . . . . . . . . . . . . . . . . . . . . 73

5.2 Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.1 User story and use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 ADL Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1 Archetype Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3.2 Template Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4 Angular 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.4.1 NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.4.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.5 GitHub OpenEHR CKM Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 Development and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1 Programming Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.1 Script process and methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1.1.1 Creating an account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

xvii

6.1.1.2 Script Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7 Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.1 Research Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.1.1 Main Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.1.2 Dealing with versioning of openEHR resources . . . . . . . . . . . . . . . . . . . . 99

7.1.2.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.1.2.2 Suggestions for the archetype governance in the openEHR CKM . . . . . 100

7.2 Script Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11710.1 Comparison of compliant archetypes between the provided repository from GitLab and the

GitHub mirror of openEHR CKM, with the respective status (”outdated”, ”compliant”,”internal” and ”not found”) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

xviii

xix

List of Figures

Figure 1.1 Small example of some EHR content . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 1.2 Use of content and exchange standards . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 1.3 Example of a FHIR Resource: Patient (FHIR, 2017b) . . . . . . . . . . . . . . . . . 9

Figure 1.4 IHE methodology process flowchart (from IHE.net) . . . . . . . . . . . . . . . . . . 10

Figure 1.5 Data content from a DICOM file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 1.6 Examples of ICD-10 codes for circulatory systems. . . . . . . . . . . . . . . . . . . . 12

Figure 1.7 Examples of diseases of circulatory systems codes in SNOMED-CT terminology server. 13

Figure 1.8 HTTP methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 1.9 HTTP methods - request and response . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 1.10REST Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 1.11HTTP Method and URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 1.12Blood Pressure archetype - mindmap view (OpenEHR CKM) . . . . . . . . . . . . 18

Figure 1.13OpenEHR package structure components . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 1.14OpenEHR ”EHR” structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 1.15OpenEHR decision algorithm - adapted from openEHR reference model class (Heard,2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 1.16OpenEHR composition structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 1.17Mismatched information models between different applications (adapted from IanMcNicoll presentation on openEHR Day London 2017) . . . . . . . . . . . . . . . . 23

Figure 1.18ADL for “Blood Pressure” archetype (from openEHR CKM) . . . . . . . . . . . . . 24

Figure 1.19Structure of “Measurement Blood Pressure” template on EHRExplorer (Marandd.o.o) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 1.20Archetype to template workflow using ADL Designer . . . . . . . . . . . . . . . . . 28

Figure 1.21Version control on a local computer vs CVCS vs DVCS (Chacon and Straub, 2014) 33

Figure 1.22Git working areas (Wilson, 2017) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 1.23Git show commit example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 1.24Git commit composition (Wilson, 2017) . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figure 3.1 OpenEHR Clinical Knowledge Manager (March 2018) . . . . . . . . . . . . . . . . . 43

Figure 3.2 Editor resource toolbar (registered user version) . . . . . . . . . . . . . . . . . . . . 46

Figure 3.3 Blood Pressure archetype historical information and status (march 2018) . . . . . . 46

xx

Figure 3.4 am.aom2.archetype Package (from openEHR Archetype specification (OpenEHR,2018f)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 3.5 Values of archetype identification parameters modified after changes. . . . . . . . . 53Figure 3.6 Changing the archetype provokes modification on the MD5-CAM-1.0.1 hash . . . . 53Figure 3.7 Structure of openEHR CKM mirror on GitHub (May 2018) . . . . . . . . . . . . . . 55

Figure 4.1 Phases of archetype creation, using the example of openEHR CKM as a clinicalmodels repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 4.2 Archetype authoring, review and publication (Leslie, 2008) . . . . . . . . . . . . . . 63Figure 4.3 Development Lifecycle with Versioning (OpenEHR, 2018b) . . . . . . . . . . . . . . 64

Figure 5.1 Server error on a under development application by wrong archetype logic (Outdatedarchetype on local repository) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figure 5.2 Use case scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Figure 5.3 ADL Designer (Marand d.o.o.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure 5.4 ADL Designer Archetype Editor - Web Interface (Marand d.o.o.) . . . . . . . . . . 77Figure 5.5 ADL Designer Archetype Editor - Architecture (Marand d.o.o.) . . . . . . . . . . . 78Figure 5.6 ADL Designer Template Editor - Web Interface (Marand d.o.o.) . . . . . . . . . . . 79Figure 5.7 ADL Designer Template Editor - Architecture (Marand d.o.o.) . . . . . . . . . . . . 80

Figure 6.1 Configuring repository connection on ADL Designer . . . . . . . . . . . . . . . . . . 86Figure 6.2 Script Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure 6.3 Script Main Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Figure 6.4 Module Get Archetypes list from local repository . . . . . . . . . . . . . . . . . . . 91Figure 6.5 Module Comparison from local repository and compliance with the openEHR CKM

mirror at Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure 6.6 Detail from comparison module, with distinction from internal, outdated and com-

pliant archetype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Figure 6.7 Module Get Templates list from local repository . . . . . . . . . . . . . . . . . . . . 93

xxi

List of Tables

Table 1.1 HL7’s Version 2.4 sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Table 1.2 HL7 CDA example for guardian person . . . . . . . . . . . . . . . . . . . . . . . . . 7

Table 1.3 Hierarchical structure for ”Medical Informatics” MeSH term . . . . . . . . . . . . . 14

Table 1.4 Comparison of reference models and artifacts between different technologies (Grieve,2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Table 1.5 Querying diastolic and systolic input values between 160 and 180 mmHg from bloodpressure measurement archetype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 1.6 Intro of NYHA heart failure archetype - slovenian variant (ADL format) . . . . . . 26

Table 1.7 “Blood Pressure” archetype in “Measurement Blood Pressure” OPT template (XMLformat excerpt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Table 1.8 List of active openEHR related software and modeling tools (march 2018) . . . . . . 29

Table 1.9 Types of clinical data repositories (Wade, 2014) . . . . . . . . . . . . . . . . . . . . 32

Table 3.1 List of active openEHR related software and modelling tools (march 2018) . . . . . 44

Table 3.2 Archetype lifecycle mapping (XML format) . . . . . . . . . . . . . . . . . . . . . . . 51

Table 3.3 Excerpt from blood pressure archetype (XML and ADL format) . . . . . . . . . . . 52

Table 4.1 Archetype custodian organization history (OpenEHR, 2018a) . . . . . . . . . . . . . 65

Table 5.1 Summary of archetype comparison analysis from the provided CKM repository withGitHub mirror of openEHR international CKM - all the versioning parameters (June2018) (n=41) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 5.2 Example of NgModule and Component decorators at app.module.ts and app.component.tsfiles from the developed script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Table 6.1 Classes ”Archetypes” and ”Templates” used to get information from ADL Designercalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 6.2 GET method calls, transformations and search . . . . . . . . . . . . . . . . . . . . . 89

Table 6.3 Summary of archetype comparison analysis from the provided CKM repository withGitHub mirror of openEHR international CKM and the openEHR CKM by majorversion difference (June 2018) (n=41) . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Table 6.4 Comparison of the local repository analysis results retrieved by the manual analysisand the developed script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

xxii

Table 7.1 Proposal example of archetype_id history changes . . . . . . . . . . . . . . . . . . . 100

xxiii

Acronyms

API Application Programming Interface

AQL Archetype Query Language

ADL Archetype Definition Language

AOL Archetype Query Language

AOM Archetype Object Model

AML Archetype Modeling Language

AM Archetype Model

ACHF Acute Congestive Heart Failure

BPMN Business Process Management and Notation

CIDES Department of Health Information and Decision Sciences

CINTESIS Center for Research in Health Technologies and Information Systems

CMMN Case Management Model and Notation

CKM Clinical Knowledge Manager

CDA Clinical Document Architecture

CDS Clinical Decision Support

CVS Control Version System

CLI Command Line Interface

DICOM Digital Imaging and Communications in Medicine

EHR Electronic Health Record

EMR Electronic Medical Record

EPR Electronic Patient Record

ECIM Medical Computing and Instrumentation Engineering

FMUP Faculty of Medicine of the University of Porto

xxiv

FCUP Faculty of Science of the University of Porto

FHIR Fast Healthcare Interoperability Resources

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

HTML Hyper Text Markup Language

HIE Health Information Exchange

HL7 Health Level Seven

HIS Health Information Systems

IHE Integrating the Healthcare Enterprise

HIM Health Information Models

HIPAA Health Insurance Portability and Accountability Act

HIMSS Healthcare Information and Management Systems Society

ISEP Engineering Institute of Polytechnic of Porto

ICHOM International Consortium for Health Outcomes Measurement

ISO International Organization for Standardization

IHTSDO International Health Terminology Standards Development Organization

ICD International Classification of Diseases

IT Information Technology

IoT Internet of Things

JSON JavaScript Object Notation

LOINC Logical Observation Identifiers Names and Codes

LDM Logical Data Model

MIM Master in Medical Informatics

OpenEHR Open Electronic Health Record

OpenEHR CKM OpenEHR Clinical Knowledge Manager

OPT Operational template

OET OpenEHR template

PHR Personal Health Record

PACS Picture Archive Communication System

xxv

REST Representational State Transfer

RM Reference Model

SQL Structured Query Language

SNOMED Systematized Nomenclature of Medicine

SNOMED-CT Systematized Nomenclature of Medicine - Clinical Terms

SVN Apache SubVersion

SDLC Software Development Life Cycle

SOAP Simple Object Access Protocol

UML Unified Modeling Language

URI Uniform Resource Identifier

URL Uniform Resource Locator

UMLS Unified Medical Language System

UX User Experience

UUID Universally Unique identifier

VCS Version Control System

XML eXtensible Markup Language

XMI XML Metadata Interchange

XDS Cross Document Sharing

XDS-IHE Cross-Enterprise Document Sharing

xxvi

Introduc on

3 Introduction

1. Introduction

In a digital era, healthcare information had to adapt itself to the current technologies. The term“e-health” is used as a natural mode nowadays, which did not happen decades ago. (Eysenbach, 2001)Gunther Eysenbach defined in 2001 this term as: “An emerging field in the intersection of medicalinformatics, public health and business, referring to health services and information delivered or enhancedthrough the Internet and related technologies. In a broader sense, the term characterizes not only atechnical development, but also a state-of-mind, a way of thinking, an attitude, and a commitment fornetworked, global thinking, to improve healthcare locally, regionally, and worldwide by using informationand communication technology”. Also it was defined by him that ”e” in e-health represents not onlyelectronics, but also a set of words that are necessary to define these terms, such as efficiency, enhancingquality, evidence-based, empowerment, encouragement, education, enabling, extending, ethical, equity,easy-to-use, entertaining or even exciting.

Within this, an electronic health record can be considered as a subset of e-health. Since the 70’s, theusage of health records has been evolving from paper sheets to digital records. Although it improved alot the medical access to patients data and corrected half of the errors on the same input data, the way ofinserting information on an EHR can differ and this can result in some misunderstanding by the varioususers (Detmer et al., 1997). Numerous new applications were developed and improved the way physiciansinteract with electronic health records (Grandia, 2017), but the underlying information model of how thepatient data should be recorded and stored was left to be developed exclusively by implementers. If usinga computer or a mobile application (tablets and phones) the modeling way of saving the patient data candiffer in both ways and also can vary from software provider to another software provider, which installstheir software in the different health providers. One of the difficulties in handling with the differentsystems is that most part of them do not use medical information standards. The software providercreates his own data models of saving data and expects this data to be exchanged with other systemsfrom a different provider in other hospital, which mostly does not happen successfully or even does nothappen at all.

To address this issue, some standards emerged and from those, one stood up the most - the OpenEHR(OpenEHR, 2017b). OpenEHR has its own international repository of clinical archetypes and templatescalled ”Clinical Knowledge Manager” (CKM). However, a new issue has risen. Each company or institu-tion working with openEHR archetypes and templates have their own local repository with a file systemor a control version system (CVS) to manage them - usually by using GIT or Subversion systems. Theselocal repositories are usually created at the start of a project by downloading copies of the availablearchetypes at a certain point in time and usually these are not updated anymore. Over the years, themain CKM (OpenEHR International CKM) had new updated versions for the different archetypes, hav-

Introduction 4

ing a very well structured management of archetypes lifecycles, with the new versions being approvedafter a community consensus. This implies that knowledge in CKM stays always updated, but that notdoes not necessarily happen on the local repositories.

1.1 State of the Art

In this chapter it will be explained what an electronic health record is, a review of the mostly usedstandards on healthcare Information Technology (IT), including the aim of each one of them, and how itis possible to improve the information systems with the use of those standards. Also, it will be exposedon broader detail what consists openEHR, the types of projects’ life cycles and the current types ofrepositories that can save various openEHR resources, including how to deal with versioning inside ofthose repositories.

1.1.1 Electronic health record (EHR)

In the old times, the medical data was collected on paper sheets and there was a huge amount ofinaccuracy, data replication, no information exchange and due to that, this way of recording patient datais less used nowadays. With the introduction of IT systems in the medical area, also known as HealthInformation Systems (HIS), all the patient information has been transfered to computers and saved indatabases on a longitudinal historical way, in order to facilitate the work of health care professionals andimproving the quality of the health care (Wilcox et al., 2014). The need to collect and store more datafrom the various encounters, and the bigger number of health care professionals using and writing onthe same system at the same time (also known as multi-user and time-sharing) made the appearance ofelectronic health records a reality. There are huge implementations of EHRs’ around the world, since theycan easily perform previous manual paper tasks in an automated and quick way. It can be considered asa digital version of patients’ paper records, but with a lot more accuracy and updated information.

Figure 1.1: Small example of some EHR content

5 Introduction

Inside of an hospital there are a lot of specialities, e.g. radiology or laboratory, that retrieve valuableinformation that needs to be understandable for the physician. The EHR system can receive this data,organize, analyze and process it, showing the information in an uncomplicated way to be comprehensibleand accessed by the authorized users and also providing control of who has been accessing the system.With this, the EHR system is a management tool for large types of information like medical patienthistory, including his personal statistics (weight and age), progresses notes, problems, medication admin-istered, demographics, allergies, multimedia sources like radiological images or ECG video loops, resultsof laboratory tests, vital signs, audit and billing information (McDonald, 1997). A bigger part of this datamay come from another systems, like the Picture Archive Communication System (PACS) that gives in-formation about the radiological files, which are usually saved in a Digital Imaging and Communicationsin Medicine (DICOM) format, or the HL7/FHIR formats that gives demographic and clinical informationabout the patient. To make all of this ecosystem being feasible to work, it is necessary to increase theinteroperability between all the different systems and use standards among them. This allows the data tobe exchanged and read easily. Furthermore, the EHRs are designed to store all the patient data duringhis lifetime in an accurate way, eliminating the need of tracking that information in medical paper record,decreasing the risk of lost paperwork and reducing the redundancy across the various files. This way,there is only one place with all the information about the patient, with all updated data that has beenreceived from other medical systems, where the patient was subjected to tests and whose data can bequeried and searched in a faster way. It can also make an analysis of all the data inserted and make analert for dangerous situations and suggest some corrections using Clinical Decision Support (CDS). Theuse of an EHR also gives the opportunity to have a big database where population studies and researchcan be made (Dick et al., 1997).

Recently, the EHRs are being used in a lot of platforms. Originally started with an application in anormal desktop workstation, using various operating systems and lately has started to be supported onmobile devices, with various applications for tablets and smartphones (Evans, 2016). The possibility ofhaving an ubiquitous access is truly appealing and can be extremely useful in cases where the authorizeduser (physician) is not currently on the hospital to access the patient information, and can even receivelive and direct information from the patient status. Also, it is possible for the others users of these mobileplatforms, e.g. patients, to have access in view mode to their own Personal Health Record (PHR), wherethey can check information about their electronic health record and add some important notes that can beuseful for the physician. Some examples can be having access about the current patient feelings by givinghim questionnaires that can filled up or other symptoms that can be reported by him. Either is possiblein some EHR systems to make automatic monitoring of the patients, using the modern technology ofInternet of Things (IoT) to flow the data between the measurement devices at the patient home andconnecting it with a mobile device, that will send the information back to the EHR. Also the future ofhealth care demands a shareable electronic health record, working in different places and systems amongvarious devices.

1.1.2 Interoperability

Interoperability is defined by the ISO/IEC TR 10000-1:1998 (ISO, 2008) as the ability of two or moreIT systems to exchange information between them and then make mutual use of the information that

Introduction 6

has been exchanged. A way to improve interoperability between systems is by using standards. Was alsodefined that in health care, the interoperability is composed by three levels (HIMSS, 2013),(Tolk andMuguira, 2003):

• Foundational – located on the lowest level, this kind of interoperability allows one SI to exchangedata with another SI that will receive it. This system does not require the ability of interpretingthe data that has been received.

• Structural – is the intermediate level and define the data format for exchange (e.g. HL7) whereit needs to exist an uniform exchange of data from one system to another.

• Semantic - is the highest level and is defined by the ability of two or more systems to exchangeinformation and then use that data. It is dependent from the others levels. For example, in thislevel ICD-10, LOINC, SNOMED, and other terminologies are used. Lately HL7, CEN (EuropeanStandards for Health Informatics) and OpenEHR are also working together to improve semanticconvergence.

1.1.3 Healthcare data standards

The use of standards is important in all IT areas. In the healthcare IT area, there are a lot of differentstandards, depending on the purpose - to content data, exchange data, terminology and security. Theyprovide a common language between systems and it is possible to share data and use that between all thehospital departments, for example, from a laboratory to the hospital or from a pharmacy to the hospital.Although a lot of healthcare standards exist, the most used types will be mentioned bellow.

1.1.3.1 Content standards: Health Level 7 (HL7 v2) and HL7 CDA

The content standards are directly connected with the transportation standards, because they definethe structure of the document and contains the data. The most used are the HL7 messages.

Health Level 7 (HL7 v2) - The HL7’s Version 2.x (V2) is one of the most implemented healthcarestandards in the world. Although it is an old implementation, still being used due to the low payloadtransmission. Is a messaging standard that has content and exchange that data between clinical systems.An HL7 message has four primary types:

• ADT (Admit-Discharge-Transfer) for patient administration;• ORM (Order Message) for orders;• ORU (Observation Result Message) that can have 2 subtypes:

– OBR (Observation Request)– OBX (Observation);

• DFT (Detail Financial Transaction) for charges.

These types are also called segments (each line of the message) and are composed by fields. The HL7message is based on “pipes and hat” encoding. Each field has information related to the patient encounter.The structure of an HL7 message has mandatory segments, such as MSH (Message Header), EVN (Event),

7 Introduction

PID (Patient Identifier), PV1 (Patient Visit Information), and others that gives information about whatis being exchanged. Also, is possible to add new segments that somehow can not fit the other declaredsegments, called the ”Z segments”, but they are not part of HL7 standard. For example, in the table 1.1is possible to check the version of this message by looking to the last components of the field from MSHsegment - 2.4, and is an ADT message type. The information of patient allergy is on the AL1 segment(penicillin) and the diagnosis is on the DG1 segment (Malignant neoplasm of liver, primary - shown ona short way, under the ICD-9 diagnosis code). The non-mandatories segments can change depending onthe type of encounter.

Table 1.1: HL7’s Version 2.4 sample

MSH|^~\&|SIEMENS|HOSPITAL−A|CERNER|HOSPITAL A|201401291848| |ADT̂ A01|1912340911|P | 2 . 4 | | |AL|NE|EVN|A01|201401291848| | |REJKB1 | | 3 | | | | |PID | |PATIENTNAMEABC123|987654|ALT789|PETTY T̂OM^^^^||19781218|M||2106−3|10144 MAPLE| | | 1 | | | | |PV1 | | I | S−2302−1^S 2302^A|C| | |1111111^PINA | | |SUR | | | | | A0||1111111^PINA| S | | S |P | | | | |PV2 | |D|42.41^ Partialesophagectomy^I9 | | | | | 2 0 1 4 0 1 2 9 0 9 0 0 | 2 0 1 4 0 1 3 1 0 9 0 0 | 3 | 3 | | | | |AL1| 1 | ^PENICILLIN|PRODUCES HIVES − RASH − LOSS OF APPETITE| |DG1|001 | I9 | |MAL NEO LIVER, PRIMARY|1988050110006|FOBX| 1 |ST|15430−2^^LN| |FULL BLOOD EXAMINATION | | | | | | FOBX| 2 |NM|718−7^Haemoglobin^LN| | 1 2 1 | g/L|115 −160| | | |F| | |201512212329

Health Level 7 Clinical Document Architecture (HL7 CDA) - The HL7 CDA is the third ver-sion of HL7 messages. The structure is composed by a header and a body, and it is based on a XML filethat specifies that body and the semantics of clinical documents. Recently is integrating the Integratingthe Healthcare Enterprise (IHE) specifications. One of the advantages is that this type can be renderedin a lot of devices and provides a more structured starting point. Is commonly used in the USA, but hasbeen substituted by FHIR. Also a new type of file, CCD (continuity of care document) was made on topof this file and is generally used by Apple.inc on their HealthKit platform.

Table 1.2: HL7 CDA example for guardian person

<guardian><code=”GRFTH” displayName=”Grandfather” codeSystem=” 2.16.840 ” codeSystemName=”HL7Rolecode”/>

<addr use=”HP”><!−− HP i s ”primaryhome” from codeSystem 2.16 .840 .1 .113883.5 .1119 −−>

<streetAddressLine>17 Daws Rd.</streetAddressLine><ci ty>Blue Bel l</ c i ty><state>MA</ state><postalCode>02368</postalCode><country>US</country><!−− US i s ”United␣ States ” from ISO 3166−1 Country Codes: 1 .0 .3166 .1 −−>

</addr><telecom value=” t e l : (781)555−1212” use=”HP”/><guardianPerson>

<name><given>Ralph</given><family>Relative</family>

</name></guardianPerson>

</guardian>

Introduction 8

1.1.3.2 Data Exchange / Transport: HL7, FHIR, IHE. DICOM and PACS

Inside of a hospital, the flow of data should be uniform, usable and easily interpreted by the infor-mation systems. A lot of standards exists for this purpose and also state how they should be integrated.Furthermore, depending on which department they will be used, there will be different standards, but allof them can connect with each other.

Figure 1.2: Use of content and exchange standards

Health Level 7 (HL7) - As mentioned previously, the HL7 message (see table 1.1) is also a formatof exchange. The number seven on referees to the layer’s of the OSI model (Application, Presentation,Session, Transport, Network, Data Link and Physical) (ISO, 1994).

These messages can be exchange by different protocol layers, but the most used are LLP (Lower LayerProtocol), also know as MLLP (Minimal Lower Layer Protocol) and HLLP (Hybrid Lower Layer protocol).Both of them can be exchanged using a TCP/IP protocol. The LLP is the most used to transmit messagesin a non-encrypted way on a local network (hospital cases). The HLLP has the advantage of incorporateerror detection and verification by using “checksums” at the end of the messages, however is just usedfor non-trustful transportations (Grieve et al., 2012). Although the MLLP is the most used, the HTTPcan be one alternative to add authorization (username/password).

Fast Healthcare Interoperability Resources (FHIR) - Is the last version of HL7 messages andcombines all the features from the previous versions. It is easily implemented due to a set of componentscalled resources. The resources can be based on administrative content, such as patient information,healthcare providers, medical or other type of devices used, locations or clinical content like medications,diagnostics, financial and others. However, there are more resources for workflow or clinical reasoningthat can be represented on various formats like XML, JSON and Turtle (RDF) (FHIR, 2017b). In thenext image is presented an example of a patient (resource) FHIR file.

9 Introduction

Figure 1.3: Example of a FHIR Resource: Patient (FHIR, 2017b)

This message format can used on different platforms, from mobile phone applications to EHR datasharing, with a strong emphasis on web standards (JSON, XML, HTTP, etc) and with RESTful archi-tecture support.

Also some examples of use cases for these standards are PHR, where the patient’s can check theirdata by using calls to the RESTful API (returning XML or JSON data) from a mobile or web portalapplication. It allows Cross Document Sharing (XDS) integrated with the IHE standards and decisionsupport. For example, in the prescription of drugs, is possible to check drug interaction with other drugs,following safety guidelines - this type of decision support come from an engine on the system interfacethat makes use of the FHIR messages. The resources are based on Pareto principle, also known as 80/20rule, that states that 80% of the effects come from 20% of causes, in FHIR case, it will only includea element if 80% of the systems will implement it (FHIR, 2017a). An element is the base type for allthe sets included on a resource, and are represented by an ID code and an extension (additional contentdefined by implementations).

Integrating the Healthcare Enterprise (IHE) - IHE is a non-profit organization established in 1998by a consortium of radiologists and IT experts (IHE, 2018). It is a set of guidelines with specifications,called “Integration Profiles/Technical Frameworks” that define how the workflow should be inside of the

Introduction 10

hospital to improve the integration, interoperability and performance/efficiency of healthcare systems -how the systems share information inside of an organization. This framework is expanded every year withnew updates and information. Furthermore, it promotes the use of standards like DICOM or HL7. Hasa group of domains for each medical area that requires the use of an information system, like radiology,pathology and laboratory, cardiology, the IT infrastructure of the organization and many more. Insideof each domain there are different profiles.

Figure 1.4: IHE methodology process flowchart (from IHE.net)

Digital Imaging and Communications in Medicine (DICOM) and Picture Archiving Com-munication System (PACS) - DICOM is a standard for storing, retrieve, print, processing, trans-mitting and display digital images and respective information between imaging medical devices andworkstations. It has protocols for the different image modalities like Computed Tomography (CT), Mag-netic Resonance (MR), radiography, ultrasonography, among others.

The DICOM file is divided in two parts, the header with metadata information and the image data.Is based on a Service-Object Pair (SOP) Class, that defines a certain functionality consisting of a com-bination of a Service and an Object, which make up a pair - that pair can be Image Storage as a serviceand the MR or CT image as a object (DICOM, 2018). The images data are usually compressed with alossless compression algorithm like GIF and PNG formats and also using lossy compression, for exampleJPEG2000, JPEG, TIFF formats - depending on what will be outcome usage of that file - medical super-vision, presentation on websites or Microsoft PowerPoint, teaching files, publications and many others(Varma, 2012). This need of compressing images is due to the huge amount of data that the differentmodalities can produce, for example, one DICOM file (.dcm) can have 5 GB of size

11 Introduction

Figure 1.5: Data content from a DICOM file

This files are saved in a system called PACS (Picture Archiving Communication System).This system can provide storage and access to the images scanned from the different modalities and it iscomposed by the acquisition devices, communication network, archive system and visualization stations.

1.1.3.3 Terminologies, classifications and nomenclatures: ICD, SNOMED, LOINC, MeSH,UMLS

The basis of a clinical information system is the encoding of the medical terms. Having a controlledterminology avoid the developers from re-inventing the wheel and allows the systems to easily commu-nicate with each other, since these codes can be understood by the different systems, but unfortunatelynowadays one of the most important basis of an EHR is still being ignored and the developers continueusing their own codification. This can happen due to non-adaptation or no knowledge of these standardsto be implemented on the system that is being created. Some of the most specific and most used clinicalterminologies are ICD, SNOMED-CT, LOINC, but each one of them were created to meet and solvespecific requirements. These terminologies are often divided in classification groups, like type of disease,body system or anatomy and present a hierarchical order. Also, they are used to facilitate the input ofmedical data, like the SNOMED-CT or LOINC standards and other standards are used to classificateand retrieve data from a system, like ICD. Normally these terminologies are connected to each-other(Bowman, 2005).

International Classification of Diseases (ICD) - ICD is the international standard for identifica-tion of diseases, disorders, injuries and other related health conditions (classification system), that canbe used for storage, retrieval, sharing and analysis of health information between hospitals, countriesand also making data comparison of diseases during different periods of time. It is mostly indicated forclinical and management use and offers a coding information for the different diseases to be used into thesystems. ICD facilitates information retrieval for secondary data purposes.

Introduction 12

Figure 1.6: Examples of ICD-10 codes for circulatory systems.

The actual version of ICD is in the tenth version, endorsed in 1990. Currently it has 16,000 codes tobe used. Will be updated to version 11 in 2018. (WHO, 2017)

International Classification of Diseases - Clinical Modification (ICD-CM) - Some nationsexpanded the code from ICD to have more information about clinical terms, adapting the nomenclatureto their own systems. The versions are dependent from each country, and some editions can reach the86,000 codes, comparing with the 16,000 from the international version. (CDC, 2018)

Systematized nomenclature of Medicine - Clinical Terms (SNOMED-CT) - The SNOMED-CT is a comprehensive coding system (terminology system) and was created to describe and definepatient data diagnosis when inserting information on a EHR. It allow the healthcare professional to usenatural medical vocabulary and checking relationships inside of the desired medical term, like findings’positions. (IHTSDO, 2017) It was released in 2002 and has more than 100,000 codes, concepts and otherabbreviations.

All these terms and respective codes can be found at SNOMED-CT terminology server: https:

//snomed.terminology.tools.

13 Introduction

Figure 1.7: Examples of diseases of circulatory systems codes in SNOMED-CT terminology server.

Logical Observation Identifiers Names and Codes (LOINC) - LOINC is a naming system fortests and observations, that define codes for clinical measurements like vital signs, ECG, PHQ-9 question-naire and many others or codes for laboratory tests results, such as hematology, toxicology, cell counts.In a easy interpretation if there is “anything that is possible to test, measure or observe about a patient”(Regenstrief, 2018b), it will be present on LOINC. Technically, it makes use of the HL7 context messageto retrieve information and is currently maintained by the Regenstrief Institute.

An example of LOINC code 806-0: (Regenstrief, 2018a)

• Fully-Specified Name (FSN): Component Analyte: Leukocytes: NCnc(Number concentration):Pt(Point in time): CSF(Cerebral Spinal Fluid): Qn(Quantity): Manual count

• Long Common Name (LCN): Leukocytes [#/volume] in Cerebral spinal fluid by Manual count• Short Name: WBC # CSF Manual

Medical Subjects Headings (MeSH) - The MeSH terms are a special kind of terminology whereall the medical literature relative to that term are indexed. It structures the medical terms hierarchicallyand permits searching those in a different levels of specificity. It is not used as a patient coding system,but it has a central role in the UMLS (Hammond et al., 2014), explained below. It was created in 2005and is maintained by the US National Library of Medicine.

Introduction 14

Table 1.3: Hierarchical structure for ”Medical Informatics” MeSH term

Information Science [ L01 ]Informatics [ L01 .313 ]

Computational Biology [ L01 .313 .124 ]Consumer Health Informatics [ L01 .313 .187 ]Dental Informatics [ L01 .313 .249 ]Medical Informatics [ L01 .313 .500 ]

Health Information Exchange [ L01 .313 .500 .500 ]Medical Informatics Applications [ L01 .313 .500 .750 ]Medical Informatics Computing [ L01 .313 .500 .875 ]

Nursing Informatics [ L01 .313 .650 ]Public Health Informatics [ L01 .313 .750 ]

Unified Medical Language System (UMLS) - UMLS is a research and development program ini-tiated in 1992 by the US National Library of Medicine and can be defined as the compendium of allthe terminologies mentioned before, ontologies, files and software. Is a system that search the differ-ent terminologies repositories and enable the development of applications that can understand medicallanguages, by mapping the different vocabularies and standards from one computer to another. Thiscan help health professionals to retrieve and integrate biomedical information, since it can communicatewith various systems and overcome the problems created by the differences of terminologies usage in thedifferent applications.It makes use of tree different knowledge sources, Metathesaurus, Semantic Networkand the Specialist Lexicon.

1.1.3.4 Information Modelling: HL7 RIM and openEHR

One of the most important standards currently on healthcare IT area is the information modelling.It describes how the information should be structured. In healthcare, lot of applications were developedand the underlying information model for saving clinical information was left to be developed solelyby system implementers. This guides to a challenge on how to connect the different information fromdifferent systems or even various devices in one database. (Huff et al., 1995) All this variety of data inputleads to a big problem - not having a functional and consistent information model dealing with all thedifferent situations. To solve this problem, some standards emerged, like openEHR and HL7 RIM. (Pihoet al., 2015)

HL7 Reference Information Model (RIM) - The HL7 organization has developed a referenceinformation model to specify the entities, roles, participations, acts and the data elements associated, tomake the different healthcare systems sustainable to communicate and exchange data with each other.For example, it represents all the physical objects like hospitals or devices and persons as entities, andevents like observations or procedures as acts. It makes use of other standards from HL7, like the v2 orv3 messages and the CDA, and identifies the life cycles of all events that those messages can carry.

OpenEHR - Has a similar approach of HL7 RIM, using a multi-level modeling methodology. Thesemodels are constituted by the base information structure for the EHR systems. OpenEHR is divided intwo-levels: the first level is composed by the Reference Model (RM), that gives the software specifica-tions, such as the generic data types – text, quantities, booleans - and data structures – list, tables, trees(Sinha et al., 2012)(Cresswell et al., 2013). In the second level, Archetype Model (AM), are presented thearchetypes and templates. The archetypes have a Lego™ model approach (OpenEHR, 2018g), giving

15 Introduction

elementary concept base to create structures - the templates. Also, the archetypes can be shared andre-used, so it is not necessary to create new archetypes for different templates. Some of the pros of usingopenEHR in EHR systems are the possibility of separating the information model from the content model.

The main difference between both information models reside in the fact that openEHR has the sepa-ration of semantics domain, that allows to involve more the healthcare professionals and IT developers inthe implementation of the system, having much more solid reference model when comparing with HL7,which is more abstract. This causes a not so easy involvement in the HL7 approach by the previouscommunity, since is more directed to application developers. Either these RMs differ on the constraintsused - openEHR makes use of templates and archetypes, that gives freedom to a community to worktogether in the implementation of new archetypes, and on the HL7 side, this is made with differenttypes of profiles (artifacts) as Domain Message Information Model (DMIM), Refined Information Model(RIM) and Common Message Element Types (CMET) (Grieve, 2016) that requires a more directed ITbackground and the creation of new profiles are not so open as in openEHR. It makes use of a big partof the information already contained in the HL7 and FHIR specifications.

Table 1.4: Comparison of reference models and artifacts between different technologies (Grieve, 2016)

Technology Reference Model Constraints

HL7 v3 RIM DMIM, RMIM, CMETFHIR Resources ProfilesOpenEHR RM Archetypes and Templates

1.2 Application Programming Interface (API)

An API sets the path and protocols of two or more different computers that can communicate in acommon language and in understandable way to each other, in order to build software applications. Thebasis of this communication is called a web service, which is identified by a Uniform Resource Identi-fier (URI). An API is composed by a set of programming functions that can be accessed over HTTPmethods, mostly for request and response calls. These calls are usually under JavaScript Object Nota-tion (JSON) or eXtensible Markup Language (XML) formats and can be made by Simple Object AccessProtocol (SOAP) or Representational State Transfer (REST) models. This kind of functionally is createdwhen a software company has the intention of having external developers or teams to develop productsby themselves, but still associated at their service.

The most commonly used HTTP methods are:

• GET - Read only access to some resource.• POST - Update or create a new resource.• PUT - Create a new resource.• PATCH - Update a new resource.• DELETE - Remove a resource.

Introduction 16

Every time there is a request from one machine to another machine, this is followed by a internalHTTP response. Each request and response have respective identifying codes, that can vary from 100to 500 and are codified in ASCII format. When a request is made, a similar message to figure 1.8 isretrieved.

Figure 1.8: HTTP methods

The values of the responses (status code) have different meanings. A successful request would get thecode 200 (”200 OK”, ”201 Created”), a redirection would get the code 300 (”301 Moved Permanently”,”303 See Other”, ”304 Not Modified”), a bad request would get the code 400 (the requested messagecould not be understood by the server (”404 Not found”, ”412 Precondition Failed”) and the 500 errorcode returns to server error (”500 Internal Server Error”) (Sundvall et al., 2013). Usually these statusare codified as:

• 1XX - informational• 2XX - success• 3XX - redirection• 4XX - client error• 5XX - server error

Figure 1.9: HTTP methods - request and response

Lately, a huge number of organizations started to prefer REST architecture instead of SOAP protocol,due to the less bandwidth and payload required by REST during communications - sending a request inJSON format is less ”heavier” than a request in XML format.

17 Introduction

1.2.1 REST API

REST is a standard for web based architecture which uses the HTTP protocol and methods forcommunication between machines. The basis is simple: A request is sent to another machine - if therequest was understood, it should retrieve a response. The most typical format on REST architecturesis JSON.

Figure 1.10: REST Web Service

When mentioning a REST API, it means that it is a programming interface based on a RESTful webservice (a web service based on a REST architecture). This will be the way of communication used in theimplementation part of the script while exchanging data with the different web repositories. In a RESTrequest, is provided an URI combined with one of the desired of HTTP methods. For example, in thefigure 1.11 is possible to see how to get a file using REST API.

Figure 1.11: HTTP Method and URI

An example of an open REST API for electronic health records based on openEHR can be accessed at:https://www.ehrscape.com/api-explorer.html and an OpenEHR REST API from openEHR foun-dation can be found at: https://www.openehr.org/releases/ITS/Release-0.9.0/docs/index

Introduction 18

1.3 OpenEHR

OpenEHR (ex-GEHR - Good European Health Record and later Good Electronic Health Record) isa specification and non-profit foundation that focuses on standards for managing clinical data. It wascreated in 2000 by a virtual community of doctors, health and information technology professionals fromEurope, Brazil and Australia (Ingram, 2016), but the research and development process of understatinghow a EHR works, remotes from 1985 in a more focused attention to the European territory. The ”motto”of this community is: “The transformation of health data from physical format to electronic format, thusensuring universal interoperability between all forms of electronic data” (OpenEHR, 2017a). OpenEHR isalso a free open-source platform which provides rules of how to work, share and store health data with theprincipal idea of separating this data from applications as an agnostic approach (Kalra et al., 2005). Someof the benefits of using this platform are the possibility of working with medical information at the samesemantic level, lowering the problems with mismatched clinical information models, strengthening theinteroperability and making possible the use of analytic functions, such as research querying and decisionsupport. The target is to create and design a way for an universal and shareable EHR (Maria Madsen,2010). It is also possible to build an independent data repository for this EHR that does not need to knowwhat kind of information will get in the beginning, because it can be modeled for what the healthcareinstitutions requires as the needs appear. OpenEHR has his own international repository, called ClinicalKnowledge Manager (CKM), with all the approved archetypes and templates, which are updated whenneeded by medical and informatics experts, after a common approval. Also, to meet specific requirementssome national CKMs were also created (OpenEHR, 2018c).

Figure 1.12: Blood Pressure archetype - mindmap view (OpenEHR CKM)

1.3.1 Architecture

The architecture of openEHR is complex, but covers the bigger part of how an EHR should behave.It is updated several times a year by medical and informatics experts. New documentation releases canbe found at: http://www.openehr.org/programs/specification/latestreleases

19 Introduction

Currently, is composed by two main levels. Each level contains different information models andspecifications:

• Reference Model (RM) - root and basis of the system.• Archetype Model (AM) - has the content for clinical or administrative data.

When relating the openEHR packages, besides the other mentioned models, the Service Model (SM)is also included and defines the basic services for integration with other health care information environ-ments, like tools or APIs.

1.3.2 Two level modeling (RM and AM)

The two level modeling approach on openEHR allows to separate the information model from thecontent. The first level is composed by the Reference Model (RM), and this is the only part implementedon software. The second level has all the information related with the clinical information, translated inarchetypes - the Archetype Model (AM). In figure 1.13, are represented the AM, RM and SM informationmodels, and the respective available packages within the models.

Figure 1.13: OpenEHR package structure components

The service model (SM) provides all the access around the EHR system, like back-end services, requestand reply services like SOAP or REST Application Programming Interface (API)’s and other source files.

The Reference Model (RM) is the base model and have a Lego™ analogy approach. It provides allthe basic information to the upper levels, like various packages with knowledges resources, data types,versioning and many others (Bacelar and Correia, 2015). In this model is also presented the “EHR”information model, the core part of openEHR, which include the “ehr” and “composition” packagesand define the content and context of main concepts like “EHR”, “COMPOSITION”, “SECTION” and“ENTRY”.

Introduction 20

The “Folder” package have all the compositions based in some similar parameter or criteria. It can bethe dates between some clinical specialities, some physician folder containing information about patientsor even a clinical team folder. The ”EHR” package is also responsible by the ”EHR ID”, ”versioning”,”contributions”, ”access control”, ”status” and has a ”COMPOSITION” (C) which manages documentsby date and hour and contain all the clinical and administrative information of the EHR. Each compositionis inside of a ”VERSIONED COMPOSITION” (VC) package (also called versioned_object), that makesthe version control of each composition (figure 1.14). The behavior is similar to a git repository, since itmakes the storage of all the different compositions that have been saved and when requested, retrievesthe versions that were saved too.

Figure 1.14: OpenEHR ”EHR” structure

Then, a “COMPOSITION” can have one or more “SECTIONs” that will make the organization andstructure of all the EHR’s content with an “ENTRY”, that can be divided by “admin_entry” and caresabout all the information to set up the clinical process, but which is not clinically relevant, or “care_entry”(“observation”, “evaluation”, “instruction” and “action”) that retrieves the clinical information about thepatient.

The care entries are what define the kind of care delivered and are composed by (OpenEHR, 2018c):

• Observation: Makes the record of a direct observation or measurement, such as body weight,blood pressure, or having the patient record in a historical retrospective.

• Evaluation: Can be a clinical opinion like a goal or a diagnosis, that have been measured orgathered and show clinical evidence.

• Instruction: It is used to record a clinical activity, providing a set of rules and instructions, andincludes cancellation or postponement. It will have an action as a reply. Can be a medication order,a service request, laboratory test, etc.

• Action: Record a step in carrying out a clinical activity, including cancellation or postponement.Can be a reply to an instruction.

OpenEHR defined a decision algorithm for choosing the correct reference model when creating anarchetype, which can help on the governance of those artifacts. This algorithm is shown on the figure1.15 and can help to have a wider view of all the components inside of an EHR along with how to createand model an archetype.

21 Introduction

Figure 1.15: OpenEHR decision algorithm - adapted from openEHR reference model class (Heard, 2010)

Introduction 22

Every entry mentioned above has a data type. The main types are:

• Text - (dv_text, dv_coded_text);• Quantity - (dv_ordinal, dv_count, dv_quantity);• Datetime - (dv_date_time, dv_duration);• Multimedia - (dv_multimedia);• Boolean - (dv_boolean, dv_state);• Uniform Resource Identifier (URI) - (dv_uri).

In figure 1.16 is possible to see how the different data types are being used in each item of the entries(e.g. blood pressure and medication management).

Figure 1.16: OpenEHR composition structure

Each entry has a cluster, a complex entry of data, such as a test result for blood pressure. Inside ofthe cluster there are different items. They represent the single input for each field, for example the cluster“blood pressure” will have the “systolic” and “diastolic” inputs. An item always have a field name, valueand data type.

The archetype model (AM) contains all the modules and packages, such as archetype definition lan-guage (ADL), archetype and template, which describe the artifacts used within openEHR. It provides allthe rules regarding how to build these artifacts.

All these information systems based on openEHR are being implemented using UML notation withclass specification. The main idea is to provide the same way of understanding and communication for

23 Introduction

the groups involved on the development.

1.3.3 CKM

When creating a clinical information system it is necessary to have a clinical knowledge repositoryto save all the information regarding the data models on use. The best way to be sure that all thesystems based on openEHR are getting the same information is by using archetypes from a ClinicalKnowledge Manager (CKM) repository. CKM is an online repository of clinical content (archetypesand templates) and also a collaboration tool, where is possible to adapt specifications to the differentartifacts. The openEHR foundation has an international repository of archetypes and templates thatis being maintained and updated when necessary by an online group of health care and informaticsprofessionals. The CKM will be explained with more details in the chapter 3 (Study I - OpenEHRCKM).

1.3.4 Clinical Models

For several years, a lot of applications have been created to deal with clinical data, addressing in-numerable purposes. This models should be capable of formalizing, structuring and standardizing dataelements for clinical use, having a particular attention to the structures and relationships of this us-age. The clinical models are responsible of organizing health information by combining the knowledge ofhealth care professionals, specification of data elements and relationship between them, and terminology,to be used in information models that will be deployed on different formats, such as HL7 or openEHR.In the case of openEHR, it offers archetypes and templates and those are connected to terminology(f.e. templates have terminology connected to ICD10, SNOMED-CT, LOINC and many others). Oneof the biggest and common problems with clinical models is the mismatched information for the sameaction between different platforms, like a desktop application or a mobile application for both patientand healthcare professional. An example can be the different way that a medication name and respectiveprescription can be saved or retrieved from these platforms.

Figure 1.17: Mismatched information models between different applications (adapted from Ian McNicollpresentation on openEHR Day London 2017)

In the case of using openEHR resources, this dilemma is easily solved, because to all the informationwill be saved or retrieved in exactly the same way on each application.

Introduction 24

1.3.5 Archetypes, Templates, ADL and AQL

The artifacts/resources of openEHR are the archetypes and templates. They are directly connected,and in a simple way, is possible to consider that one template is a set of archetypes, but the templateis by himself, a giant and specialized archetype. The Archetype Definition Language (ADL) is definedby the openEHR foundation as “ an abstract human-readable and computer-processable syntax and canbe hand-edited using a normal text editor”. It is the language used inside of the archetypes. Since 2002,ADL has changed from version 1.2 to version 2.0.

Figure 1.18: ADL for “Blood Pressure” archetype (from openEHR CKM)

The Archetype Query Language (AQL) is what makes possible querying the ADL. The possibilityof querying archetypes with the AQL offers many benefits, because it is prepared to query a databasethat is perfectly defined by the openEHR RM model, against querying one proprietary database withStructured Query Language (SQL) that is being filled with information from a specific form, with a hugepossibility of various elements. In the next figure is possible to see what an AQL query looks like:

Table 1.5: Querying diastolic and systolic input values between 160 and 180 mmHg from blood pressuremeasurement archetype

s e l e c te/ehr_id as EHR_ID,a_a/data [ at0001 ]/ events [ at0006 ]/ data [ at0003 ]/ items [ at0004 ]/ value as Systo l ic ,a_a/data [ at0001 ]/ events [ at0006 ]/ data [ at0003 ]/ items [ at0005 ]/ value as Dias to l i c

from EHR econtains COMPOSITION acontains OBSERVATION a_a[openEHR−EHR−OBSERVATION. blood_pressure . v1 ]where

a_a/data [ at0001 ]/ events [ at0006 ]/ data [ at0003 ]/ items [ at0004 ]/ value/magnitude>=180 ora_a/data [ at0001 ]/ events [ at0006 ]/ data [ at0003 ]/ items [ at0005 ]/ value/magnitude>=160

25 Introduction

1.3.5.1 Understanding the archetypes

To understand the way the archetypes are based and how they work, is necessary to consider thebasics of ontology, which are defined as “a set of concepts and categories in a subject area or domainthat shows their properties and the relations between them” (Oxford 2018). Thus, an archetype is thekey feature of separation between information models and domain models, that defines how to captureclinical data (Beale and Heard, 2007b). It is a set of data elements and other data groups with formaldefinition of knowledge domain, for an healthcare information system and can be reusable in differentsituations.

An archetype can be considered as the basis of a template and provide a standard clinical contentspecification (Maria Madsen, 2010). For example, the archetype “Blood Pressure” includes all the dataelements that can be used on blood pressure measurement template. Some of these points can be repeatedon others templates that are under the same topic. It is also possible to compose or decompose anarchetype and include the data elements from it in another archetype, like the case of “Heart Rate”archetype being decomposed and including some of these elements into the “Fetal Heart Rate” archetype,specializing it in this way. If necessary, is possible to add external terminologies to them, such as IDC-10,SNOMED, LOINC, among others.

There are several types of archetypes, some of them have been mentioned previously:

• “Composition” that contains all the information stored in a EHR and has “sections” with different“entries” archetypes;

• “Section”, correspondent to headings;• “Entry”, the unit of information, like systolic blood pressure, heart rate, etc. These entries are

divided in four sub-types:

– Observations;– Evaluations;– Instructions;– Actions;

• “Cluster”, archetypes for use into any “entry” or even another “cluster”.

Another relevant aspect of the archetype is that they are not an internal part of software or database ofa system, but more like a ”configuration”. They provide validation of data and the possibility of queryingdata by using AQL language, very similar to SQL. Although the openEHR CKM has a big repositoryof archetypes, in very specific cases, some of them needs to be rebuild to fill up the client requirements.Still, they are based and checked by clinical experts.

1.3.5.2 Archetype specialization

When an archetype is called ”specialized”, it means that is based on a parent archetype, but ithas a different format due to fulfillment of special requirements, which the parent archetype could notmet. An example of it can be seen in the table 1.6, where the ”nyha_heart_failure” archetype that hasbeen specialized to ”nyha_heart_failure-slo” to meet some special slovenian specification for the clientrequirements. An archetype of this type has present on the ADL format the announcement of being aspecialization.

Introduction 26

Table 1.6: Intro of NYHA heart failure archetype - slovenian variant (ADL format)

archetype ( adl_version =1.4; uid=69453c5f−b816−40d9−98a4−a2a1a1164877 )openEHR−EHR−CLUSTER. nyha_heart_failure−s l o . v1

s p e c i a l i z eopenEHR−EHR−CLUSTER. nyha_heart_failure . v1

concept[ at0000 . 1 ]

languageoriginal_language = <[ ISO_639−1: : e n ]>

Since it is a specialization, these type of archetypes will be created in a more internal way and arenot so shareable like the archetypes present at the international CKM, only if submitted to it and afterthe peer reviews approval. Although there are some examples on the international CKM, the status ofeach one of these archetypes are commonly draft or pre-draft.

1.3.5.3 Understanding the templates

One template aggregates and defines the data sets within the archetypes. When creating a template,this does not need the same amount of preparation and design used to create an archetype. It is dependenton the use case, speciality, domain and location, and makes the definitions for the content of a form orreport. In the figure 1.19 is possible to see the structure of the “Measurement Blood Pressure” template.

Figure 1.19: Structure of “Measurement Blood Pressure” template on EHRExplorer (Marand d.o.o)

It is mandatory to have a root archetype (composition), which is in this case a “report” type. Then,this composition needs to be filled with specific archetypes for the use case of this template, that will fillup the slots, such as “Blood Pressure” (observation), “Service” (action), Medical devices (cluster) andHub (cluster). It is not necessary to have all the archetype data items included if they will not be used.For that, it is possible to constrain the options by changing the multiplicity of the occurrences (e.g. [0..0],

27 Introduction

[1..1], [0..*], etc) making the mandatory items being optional or vice-versa. (Beale and Heard, 2007b)

There are two types of templates: Operational template (OPT) and OpenEHR template (OET). The(OET) only has the identification of the archetypes used to create the template and constraints done.The operational template (OPT), which is a finished and compiled template that produces a flattenedformat expressed in XML, that will be read and used by a machine. It makes the joint point betweensemantic specifications and the different software files that can be used by developers, like XML SchemaDefinition (XSD), Java and C# API’s, GUI screen forms and others.

Table 1.7: “Blood Pressure” archetype in “Measurement Blood Pressure” OPT template (XML formatexcerpt)

<archetype_id><value>openEHR−EHR−OBSERVATION. blood_pressure . v1</value>

</archetype_id>

<term_definit ions code=”at0000”><items id=” text ”>Blood Pressure</items><items id=” descr ipt ion ”>The l o c a l measurement of a r t e r i a l blood pressure .</items>

</term_definit ions>

<term_definit ions code=”at0001”><items id=” text ”>history</items><items id=” descr ipt ion ”>History Structural node .</items>

</term_definit ions>

<term_definit ions code=”at0004”><items id=” text ”>Systo l i c</items><items id=” descr ipt ion ”>Peak systemic a r t e r i a l blood pressure −

measured in s y s t o l i c or contract ion phase of the heart cyc le .</items>

</term_definit ions>

<term_definit ions code=”at0005”><items id=” text ”>Dias to l i c</items><items id=” descr ipt ion ”>Minimum systemic a r t e r i a l blood pressure −

measured in the d i a s t o l i c or re laxat ion phase of the heart cyc le .</items>

</term_definit ions>

The OPT is a dynamically created object from an OET template, which is based on openEHRarchetypes. The workflow of archetype creation, until getting an OET and OPT templates is shownon figure 1.20, using one of the openEHR tools, ADL Designer, as a modeling and integration tool andThink!EHR platform, an ”high-performance solution designed to store, manage, query, retrieve and ex-change structured electronic health record data based on the latest release of openEHR specifications.”(Marand, 2017).

Introduction 28

Figure 1.20: Archetype to template workflow using ADL Designer

1.3.6 Tools

Since the international CKM is managed by an online community that can create, edit and publishartifacts, there are some modeling tools to help with the creation of archetypes and templates.

The current supported application for openEHR modelling is ADL Designer, an online tool createdby Marand that allows to parse, serialize, flattening and validate the archetypes, and it is the tool thatwill be used in development part of this dissertation. Is compatible with the version 1.4 ADL archetypesand 1.4 OPTs. Also, it allows direct connection with other online repositories, like Github, Bitbucket,Google Drive, Dropbox, One Drive or local and central repositories like GIT or Subversion.

There are other desktop tools created by different companies (see table 3.1 in the next page), such asOcean Informatics’ Archetype Editor (AE) and Template Designer. Those were the most used tools andhave been used since the beginnings of archetype modeling, but currently are not supported anymore.The Archetype Workbench is also a very useful tool that test the accuracy of the archetypes and theirbased relationship. All the existing tools can be downloaded from the openEHR modeling tools page.

29 Introduction

Table 1.8: List of active openEHR related software and modeling tools (march 2018)

Software name Description Technology Link for download

ADL Designer The tool allows visual authoringof ADL 2 archetypes and tem-plates including full archetypeparsing, validation, flatteningand serialization. Backwardcompatibility for existing ADL1.4 archetypes and export to Op-erational Template (1.4 OPT)is also supported. Work with:ADL 2 archetypes, templates,ADL 2 OPTs, ADL 1.4 OPTs.

WEB(JavaScript,HTML, etc).

http://ehrscape.marand.si/designer/

Archetype Editor(AE)

The Archetype Editor is cur-rently the main tool in use forauthoring archetypes as found onopenEHR CKM and elsewhere.It is Unicode-enabled and workswith archetypes in any language.Work with: ADL 1.4 archetypes.

MicrosoftVB.NET.

https://www.openehr.org/download_files/archetype_editor/archetype_editor_2.8.972.1-windows_32bit.exe

Template Designer The Template Designer is thetool required for editing ’.oet’(pre-ADL2) templates. .oet tem-plates; ADL 1.4 OPTs; ADL 1.4archetypes.

Windows,.Net.

https://www.openehr.org/download_files/TemplateDesigner/TemplateDesignerSetup_2.8.94.2.exe

ADL2 workbench(AWB)

Reference model-driven visualIDE for parsing, compiling, an-alyzing, converting and edit-ing archetypes and templates.Built on the reference ADLparser. ADL 1.4 (read), ADL 2archetypes and templates (read-/write).

Windows,Linux andMac OSX.

https://www.openehr.org/downloads/ADLworkbench

ADL2 command-line compiler(ADLC)

A command-line version of thecompiler used inside the ADLWorkbench (AWB). ADL 1.4(read), ADL 2 archetypes andtemplates (read/write).

Windows,Linux andMac OSX.

https://www.openehr.org/downloads/ADLworkbench

LinkEHR Editor The LinkEHR Editor works withmultiple reference models andlanguages. Reference modelscan be plugged in in XML-schema or openEHR BMM (ba-sic meta-model) format. .oettemplates; ADL 1.4 OPTs; ADL1.4 archetypes.

Java. http://veratechnas1.synology.me:6969/linkehr/getlinkehr.html

ADL Text EditorModes

ADL syntax plug-ins, syntaxfiles and other support for texteditors, including gvim/vim,emacs, Notepad++, Textpad,and Kate/KDevelop.

Windows,Linux andMac OSX.

https://openehr.atlassian.net/wiki/spaces/dev/pages/6553628/ADL+Text+Editors

Introduction 30

1.4 Life cycles of projects

Working on a project requires to pass every phase associated to it from the start until the finish phaseline. All these phases compose the life cycle of a project. It is necessary to evaluate all the phases ofthe project, to know if it will be feasible to maintain and how to deal with them. Since the aim ofthis dissertation is related with software development, it will be presented a special framework that iscommonly used on this area, the Software Development Life Cycle (SDLC) (Wilcox et al., 2014). Thiskind of framework presents a high level view of the projects life cycle. The usual phases of a projectunder the SDLC framework are divided in six parts:

1. Initiation - The beginning of a project starts when an need is found. Proposal concepts are created.

2. Planning/Analysis - Included the concept of the project, documentation, analysis of cost-benefit,risk management and feasibility of the project. Also the planning of resources needed and a detailedfunctional requirements are done on this phase.

3. Design - Transition of the obtained requirements to technical approach, including business rules,process diagrams, screen layouts and big parts of pseudocode.

4. Development - The biggest part of the software coding is made on this phase. The programmersmake use of the technical requirements and documentation made in the previous phase as theyprogram the code and, when they are not clear about how some requirement or design featureshould be done, are assisted by analysts to solve their questions. Also during this phase, integrationand testing is also done, to check if the requirements are being met in a correct way.

5. Implementation - In this phase the project go into ”live” mode. Preparation for installationof the product, devices, infrastructures need to be implemented and tested. User training is alsopreformed before the project goes live. Another important step is the verification and validation ofthe project, to ensure that the requested requirements have been met and it works according theoperational requirements.

6. Maintenance and control - After the project goes live, it is necessary to give support to the needsof the organization, to be sure that it works as desired and to correct bugs that can eventuallyappear. Some updates with new features may also need to be installed when new versions ofthe system are released and monitorization of data repositories need to be done to ensure properoperation.

Different methods on how to deal with the project processes and phases can be used inside of theSDLC framework, which describe the ”day by day” methodology that is being followed by the devel-opment team. The most common methods used on healthcare systems development are the WaterfallModel and the new Agile Models. (Wilcox et al., 2014)

In the Waterfall model, the phases of the project should happen in a sequential way, which requiresthat the original project requirements will be very well prepared in the beginning of the project, withcomplete functional specifications, and will not change during the next phases of the project. The mean-ing of this approach is that having a solid and correct requirements and design from an initial phase,

31 Introduction

can be saving time and effort in the next phases of the project. Since a lot of clients do not know thenew requirements that they can have before working with a functional prototype, this methodology isless used nowadays, because it is really hard to make further changes of the requirements during thedevelopment of projects and it can also provoke high costs to make changes on it.

In case of agile models, also called the modern software development approach, they provide moreflexibility to changes, in contrast to the previous model. In this approach, a face-to-face communicationis preferred instead of written documentation and there are meetings from time to time (e.g. some daysper week in the beginning the day), with the development team, where is discussed what have beendone, further planning, new requirements to implement, testing activities and potential problems thatcan appear are exposed and managed more quickly. Some typical names from this approach are Scrum,Kanban or Lean.

Lately, new aditions to the agile models have shown that can improve even more the development ofan application (Kniberg, 2017). A curious case is the engineering culture of Spotify, called the ”Spotifymodel” based on all the previous agile methods, that divides groups by skills or interests with the aimof exchange the best practices, experiences and challenges in order to obtain synergies from all to enrichthe company productivity and internal knowledge (Kniberg and Ivarsson, 2012).

1.5 Repositories

A repository is a storage location for software packages or other sets of data that can be retrieved orinstalled on a variety of computers. In the development area, it allows implementers to work togetherin the same data and commit their versions to that repository using a Version Control System (VCS),providing a easy way to collaborate in the product development. Inside of a company, when differentprojects are being created, each one of them will have different data requirements and it is impossible tomanage all the data from that projects with only one repository. One of the most interesting things abouta repository is the possibility of having a version control of the artifacts that are being saved, allowingto recover the previous versions if something went wrong with the new deployment.

1.5.1 Types

There are various types of data repositories. On healthcare they exist to fit various purposes, suchas, saving information from an EHR, like patient clinical data, longitudinal observations for studiesand research, information from others healthcare department systems like laboratory, pharmacy or evenradiology that will have his own repository of images and meta-data on DICOM files, among many others.Some repositories are public and others private, with some level of restriction among users. (Wade, 2014).In this dissertation, two repositories will be used for saving openEHR artefacts and both are based on acollection (Marand ACHF CKM on GitLab) and federation (openEHR International CKM) type. In thetable 1.9 are presented the types of repositories that commonly exists in healthcare.

Introduction 32

Table 1.9: Types of clinical data repositories (Wade, 2014)

Repository type Definition

Study A database that collects observations for a specific clinical researchstudy.

EHR A database of observations made as a result of direct health care.Registry Observations collected and organized for the purpose of studying or

guiding particular outcomes on a defined population. Associatedstudies are either multiple or longterm and evolving over time.

Warehouse A repository that adds levels of integration and quality to the primary(research or clinical) data of a single institution, to support flexiblequeries for multiple uses. Is broader in application than a registry

Collection A library of heterogeneous data sets from more organizations than awarehouse or more sources than a registry. Organized to help usersfind a particular data set, but not to query for data combined acrossdata sets.

Federation A repository distributed across multiple locations, where each loca-tion retains control over access to its own data, and is responsible formaking the data comparable with the data of other locations.

1.5.2 Version Control Systems (VCS)

When software is being developed, it can never be considered as totally finished, since there are alwaysbugs that will be detected, design that would be changed or even algorithms to be improved. Usually,this requires a lot of changes made by a lot of developers in the same code, and due to that, it is necessaryto use a system that can record all the adjustments that have been made. The best solution for this,is having a VCS that has the duty of tracking all the changes made in a specific software (Loeliger andMcCullough, 2012). It can determine what was changed inside of a repository or other related softwareclass and also know who was the responsible of that change. Nowadays, in the era of big data, havingcontrol of different versions of digital documents can be really convenient in case of a sudden lost of thatfiles. For example, if a developer wants to make a record of all the changes and have a version of eachchange, he should get a Version Control System (VCS) since it can register and records all the changesmade to a file or a set of files that can be recalled later. Also, it is possible to revert files or even theentire project to previous states, making comparisons of versions, check which changes were made andby who they were made among others. There are three types of VCS:

1. Local, with a simple database that is fed by different versions of the same file and keep all thechanges under revision control. Some operative systems already have implemented this functionalityin their environment.

2. Centralized, where various users need to collaborate with each other on different systems, butstill need to use the same server that contains all the versioned files. These centralized versioncontrol systems (CVCS) are also known by CVS, Subversion and perforce. Although it has a lotof advantages, like everyone knowing and being informed about what is going on in the project, itcan also have a big constrain if the server shuts down, causing a break on the collaborators workthat were using that server, until it goes up again, or even losing the versions they were working

33 Introduction

at the time that the server went down, if they were not saved before. Also, because it is saved inonly one server, if the disk become corrupted, some versions or the entire project can also be lostforever and will be irreversible to take them back if there was not made any backup previously.

3. Distributed, also known as Distributed Version Control Systems (DVCS). These systems came tosolve the common problems from the CVCS, as the example of server shutdown. The DVC systemsallows the user to make a fully mirror of all the available data on the repository (server), includingthe full story of it to his own computer. Each computer connected to that server will have a cloneof the same repository that is getting updated by the different users. Each submitted new versionis called a “commit”. If some of the computers that are collaborating with the server gets broken,it is easily substituted by a new clone of the main repository. The most popular versions of thesesystems are Git, Mercurial, Bazaar or Darcs.

Figure 1.21: Version control on a local computer vs CVCS vs DVCS (Chacon and Straub, 2014)

1.5.3 Git

To help with the maintenance of code during the development of software, having a full story ofchanges made in a data repository and also a version control over it, some applications were developed.The most used one is called GIT, which is a VCS, created by Linus Torvalds for development of Linuxkernel and ended up also being used by many other projects due to the benefits that can come from it(Chacon and Straub, 2014). When the data is being saved in a GIT repository, nothing will be ever lost,since it is always possible to rewind to the previous results and check what was generated by the differentversions of the data. In case of conflicts, like having the same code being changed by two different usersand submitted to the same repository, GIT also make automatic notifications about these conflicts, in away to advice the user that he can overwrite some information. The projects saved on GIT are dividedin two parts and combination of this two parts is what form a repository (Wilson, 2017):

• Files and directories of that files.• Extra GIT information about the data saved: this information is saved on a directory ”.git” and is

present in the root directory, which should never be modified to maintain the repository integrity.

It is possible to divide the working area of GIT in three parts, the ”working directory”, ”staggingarea” and the ”.git directory”. The ”stagging area” is a special area that takes care of the files that areon hold to be submitted (commit) to the repository.

Introduction 34

Figure 1.22: Git working areas (Wilson, 2017)

The working directory is where the current file or code is being modified. Different versions of thatfile can be put inside of the ”stagging area”, which behaves like a box where it is possible to put ortake out things, but once they are submitted or ”commited” to the .git directory, is not possible tomake further changes on it. There are a lot of functions that can be used to manage the informationinside the repository with GIT, always preceded with the ”git” label. Some examples are ”git status” tocheck the repository status, ”git diff ” to check the differences that have been made in the repository orbetween versions of files, or even the ”git commit” that sends the data to the repository with some extrainformation.

Git has a multi-level structure to save the data. After ”commiting” the data to the repository, sectionsand subsections are created to manage the all the data that has been sent, called ”Tree” and ”Blob”.Each commit made to these sections, is composed by a ”hash” which is a string with 40 hexadecimalcharacters, created randomly by a hash function. This hash gives a unique identifier to each commit sentto the repository and this enable a GIT system to share the data in a efficient way between repositories.The basis is simple: if two files are exactly the same, they will have the same hash string and vice-versa.A typical look of a hash can be ”5ac632e3a1be3749e1758f195f719957a2e37e12”. Since it is too big to behandled every time, when it is necessary to check or compare some commits, it can be used only the first5 to 8 characters for that.

In the figure 1.23, is possible to see how information is being sent to repository. The commit sends theinformation related to the author, plus a log message (some comment made by the author) and propertiesof commit, like the date and hour of submission.

Figure 1.23: Git show commit example

35 Introduction

Then this information is sent to the ”Tree”. The tree is composed by all files names and locationscommited to the repository and makes the track of these files. The ”Blob” is the unique version of everyfile, which can contain any type of data. These blobs can be shared between trees.

Figure 1.24: Git commit composition (Wilson, 2017)

Other interesting feature on GIT are the branches. In every GIT repository there is a branch called”master” where the principal workflow of data (main directory) occurs. This is also the branch on pro-duction. Then, there are other branches that can be created from the master branch and will work like asub-directory. When these ”sub”-branches are created, all the data from ”master” branch is replicated/-copied. After the branch has been created, every change made in it, does not affect the ”master”, butin case of using the git command ”git merge”, all the changes made in this branch will get merged andthen commited to the ”master” branch. In case of merging branches, for example, between a master andanother branch, this means that one commit made to the repository can have two parents.

Every repository can be cloned. With this, GIT know what was the original repository and will createa remote repository pointed to the original one, usually with the name ”origin” and an Uniform ResourceLocator (URL) linked to it. This is the case of having a local repository (master) and a cloned repository(origin) in online repository services like GitHub or GitLab. With git is possible to have a copy of aproject in the personal computer in a offline mode, but if there are any changes that should be replicatedin the distributed repositories, these changes will only be ”commited” to GitHub or GitLab if there is anonline access.

Introduction 36

1.5.3.1 GitHub and GitLab

GitHub and GitLab are web-based (or cloud-based) collaborative repositories that interacts with GIT,mostly used to save code from developers, but it can also saves another types of data. GitHub projectscan be made public and shared among everyone, which are used for open source software. These projectscan also be private, if paying a plan. GitLab is similar to GitHub, but is more used in a enterpriseenvironment. This is due to the authentication method: on GitHub is only possible to set permissionsbased on read and write access. On GitLab, it is possible to change users permissions based on their role,so controlling teams is easier. Also, it provides unlimited private repositories for free.

Although it seems that GitLab is less popular that GitHub, it is because GitLab entered on themarket few years after GitHub, which was already very well positioned in this area (Peham, 2017). Bothservices have very solid REST API applications, that allows developers to make HTTP requests with theinformation that they want to get from the hosted repositories.

1.5.4 Semantic Versioning

When a software application is being developed, it passes through many changes. During the years,the management of software suffer a lot of variations and, to help dealing with this issue, a versioningguideline was made, the ”semVer”, which is followed by many implementers. The consecutive changes insoftware were hard to maintain and after some time, working along with so many new releases could bea challenging job. Within this, the ”semVer” defines that each one of these changes can be divided in”major”, ”minor” and ”patch”. These divisions are labeled with a tag containing numbers separated bydots, respective to each version. For example, for an initial development release, the version should be(0.1.0). In case of the minor release, it should be incremented by 1, e.g. (0.2.0). When the software goesinto production, the major number should increase (1.0.0). Summarizing, if it is given a version number(Major.Minor.Patch), the incrementation is made when: (Preston-Werner, 2018)

• Major version - incompatible API changes have been made;• Minor version - is added functionality in a backwards-compatible manner;• Patch version - backwards-compatible bug fixes were made.

OpenEHR archetypes and templates are following this way to versioning the different releases. Whenan archetype is being revised, it takes a special number based on these “semVer” rules. Each archetypethat is currently on use, has an internal version that follows the next schema:

• (majorVersion.minorVersion.patchNumber) - e.g. (1.1.1).

It can also have an optional version modifier, the ”alpha element”, in case of being considered as anunstable archetype or as ”release candidate”. If an archetype was never published (draft), it will have a“majorVersion” of 0 (e.g. 0.1.1) and this is also indicated in the archetype name, preceded by ”.v” (e.g.openEHR-EHR-OBSERVATION.blood_pressure.v0). (OpenEHR, 2018c)

This procedure will be explained in detail in the chapter 3 (OpenEHR CKM).

Objec ves

39 Objectives

2. Objectives

The aim of this dissertation was to study and find a suitable way of having the different openEHRbased local repositories updated and compliant with the international openEHR CKM. To achieve it, thefollowing studies were made:

1. How the CKM works, historical information, features and functionalities and how the verificationof new versions is made;

2. Study state of art methodologies used for managing software and document life-cycles;3. Apply study to the proposed methodology for the current problem;4. Development and implementation of the proposed methodology and verification of results.

Although the governance of the international openEHR CKM is managed on a continuous improvementway by an online community of mostly health care and informatics professionals, reviewing constantlythe different artifacts, the same does not happen with the local repositories on several companies. Theexpected outcomes were:

1. Documentation of how to deal with the versioning of openEHR archetypes and templates on newand ongoing projects of local repositories;

2. Creation of a script that will automatically run on the local repositories connected to ADL Designerto search new major versions of archetypes on CKM and allowing to download them to the localrepository.

It is expected that the methods that were implemented for updating these openEHR artifacts onlocal repositories, have a prevalence in the improvement of added value in the final application, which isdependent from the provided input data of the local repositories.

Objectives 40

Study I - openEHR CKM

43 Study I - openEHR CKM

3. Study I - openEHR CKM

The present study was made during the period of January 2018 until March 2018. Due to constantremodeling to improve the user experience and content on openEHR CKM, several changes and newfeatures may be noticed after the publication of this dissertation.

The openEHR Clinical Knowledge Manager, commonly known as openEHR CKM, was created in April2009. It is a product from Ocean Health Systems (ex-Ocean Informatics) and is under the managementof the openEHR community. Has become the main international web tool that makes the managementof clinical models. The first introduction of CKM had as main objective the creation of an archetypelibrary, development of a review process with achieved content consensus, publication and governance ofthe artifacts. Since then, the possibility of adding terminology and other terminology specific subsets(SNOMED-CT, LOINC, ICD) has been included. It offers a free registration for individuals from allaround the world, focused on giving added value to the repository on a voluntary basis. All non-technicalhealth care area professionals are also encourage to contribute, is not a requirement to be a physician toredound. Is possible to purpose new artifacts (archetypes, templates), suggest corrections and participatein discussions, translate archetypes to other languages, watch or adopt archetypes. All the changesmade to an archetype are subjected to a consensual decision from all reviewers before being published.The CKM has a model governance system that supports all the life cycle of archetypes, templates andterminology. In 18 January 2018, it contained 1840 users and 679 archetypes (respectively 11,8 and 4,1times more than May 2009 (Conde and Berry, 2010). This growing up stand is only possible due tohaving an active online community that is constantly working together to determine clinical definitions.

Figure 3.1: OpenEHR Clinical Knowledge Manager (March 2018)

Study I - openEHR CKM 44

3.1 Instances of CKM

Inasmuch as there are different requirements between different countries or even projects, others in-stances of CKM for national registries had been made, such as Norwegian Nasjonal IKT CKM, AustralianDigital Health Agency CKM, NHS England CKM, Shared UK CKM (Apperta Foundation, Scottish Gov-ernment) and the Slovenian MoH CKM. The following table presents the active national and internationalCKM instances available.

Table 3.1: List of active openEHR related software and modelling tools (march 2018)

Name Description PublisherOrganiza-tion

PublisherNamespace

PrimaryLanguage

Git Repository

openEHRCKM

The CKM forthe internationalopenEHR commu-nity.

openEHRFoundation

org.openehr English https://github.com/openEHR/CKM-mirror

AustralianDigitalHealthAgencyCKM

Hosted by Aus-tralian DigitalHealth Agencyfor the Australiannational digitalhealth program

AustralianDigitalHealthAgency

au.org.nehta English N/A

UKClinicalModels/ Ap-pertaCKM

The CKM for re-sources developedcollaborativelywithin UK projects.

UK ClinicalModels /AppertaFoundation

uk.org.clinicalmodels English https://github.com/ClinicalModelsUK/ckm

NorwegianCKM

Hosted and man-aged by the Nor-wegian nationaleHealth program.

NasjonalIKT

no.nasjonalikt Norwegian https://github.com/Arketyper-no/ckm

SlovenianCKM

Hosted and man-aged by the Min-istry of Health inSlovenia.

si.ezdrav si.ezdrav Slovenian N/A

AlbertaCKM

Hosted by theCanadian AlbertaHealth Services

AlbertaHealthServices,Canada

ca.ahs English N/A

CKMTestserver

Hosted by OceanInformatics fortesting and demo-ing purposes

Ocean Infor-matics

com.oceaninformatics English N/A

These instances are totally independent from each other. The archetypes inside of each instance candiffer with the related use case and even when making an user registration/account in one domain, thisaccount will not be created or replicated in the other domains.

45 Study I - openEHR CKM

3.2 Roles

OpenEHR CKM offers three levels of management roles (OpenEHR, 2018c):

• Systemwide;• Subdomain;• Project/incubator.

The international openEHR (main domain) is ruled by the systemwide role. This role also offers adifferent case of sub-roles as administrators: “Clinical Knowledge administrator” and “Technical admin-istrator”, that gives complete rights for CKM administration, although notifications can differ betweenboth. Then, there are other sub-roles like “classes modifier”, “classifications modifier”, “scheme modi-fier”, “scheme translator” and “release set modifier”.

The other role is located in the subdomain level, called the “subdomain admin”, that manages oneof the instances from OpenEHR CKM, the national domains: Norwegian CKM, UK Clinical Models,NEHTA CKM or Alberta Health Services. In the case of project/incubator level the roles are “editor”and “reviewer”.

When a user makes his own registration on the OpenEHR CKM, a normal user role is assigned tohim. Then, is possible for the user to define what is his health domain and profession. Depending on theprovided info, he can be part of the upper role levels. Also a “normal user” can review artifacts that arenot owned by any other project or incubator, but is not assigned to any of those roles mentioned before.

3.3 Features and functionalities

Despite being a repository for openEHR artifacts, where it is possible to upload or download thesecontents, the CKM has more functionalities. A guest, a common user that is not registered on theopenEHR CKM portal, is allowed to search archetypes, templates or term sets in the international repos-itory, including as well the other national instances and projects. Also, there is the possibility to checkanalytical and statistical data on the repository, including total number of uploaded archetypes, infor-mation of registered users (professional status, world distribution), last uploaded and updated artifactsand projects, and give bug reporting in case of malfunction of the repository. The CKM offers free userregistration and those accounts can have different roles, that have been already mentioned above. Is pos-sible as a registered user to purpose and submit creations or changes of archetypes that will be reviewedby the OpenEHR community, join projects and create incubators, set preferred views of subdomains (e.g.national instances) and respective projects/incubators, download archetypes or templates with draft andpublished status, make language translations of the artifacts with the possibility to watch and adoptthem and participate in content discussions.

One of the most interesting features is the way the information of the chosen archetype or template isshown on the CKM and how it is possible to manage them. After searching and opening an archetype,if the user has an account, a special kind of toolbar is associated to it. This toolbar has various optionsand views that can be suitable for a different type of users - a healthcare professional would prefer tosee the structure of an archetype in a mindmap view and a informatician would prefer to see that asan XML file. The available information views are the tabbed view, mindmap and XML. Each one of

Study I - openEHR CKM 46

them gives information about the header, attribution, data, state, protocol, pathway, related events andthe respective reference model associated to that archetype. The header, only available in the tabbedview, contains the specific content like the concept name associated and respective description, keywords,purpose of the archetype, information about use and misuse of that content, other additional identification(build UID, major version ID, MD5 hash), authors and contributors (editors and translators).

Figure 3.2: Editor resource toolbar (registered user version)

Other interesting section is “archetype history”, which offers all the historical information from theselected archetype, being possible to see all the changes that affected the content development in eachtrunk and respective branches (resolved, outdated, committed and active) of the repository. Each com-mitted branch to the trunk was done after consensus by all the openEHR reviewers team. If new changesare necessary, new branches can be open in the new version of the trunk. It is also possible to checkand download the previous versions of the current archetype. The section “related resources” gives infor-mation about where the archetype is being used, in which template is inserted, the parent and childrenrelationships from it and if there is any predecessor or successor for this archetype.

Figure 3.3: Blood Pressure archetype historical information and status (march 2018)

Also on this toolbar, there is an analytical view, called “Status” that gives information about thecurrent status of the archetype (Initial/pre-draft, draft, review suspended, team review or published),how many reviews rounds have been made, reviewers and total reviews were involved, recommendationsfrom the latest review round, the background of reviewers community, terminology and translation status.With all the functionalities mentioned, it is possible to conclude that the possibility of having an onlinecommunity working together on this web tool can give an added value to the improvement of health careIT, since it can decrease time and costs between the face-to-face meetings, it provides online versioningmanagement and mutual revision with proper discussion.

47 Study I - openEHR CKM

3.4 Management of artifacts

All the management made with the artifacts are directly done in the openEHR CKM or in the othernational instances. Depending on the user role, openEHR CKM offers a model that allows to easilysuggest changes and updates on an archetype by revising it. For that, a ”branch” can be created for therevision, where is included the information of who has created the submission and a log message withinformation related to this branch. During all the steps of revision, the artifact will be checked by healthinformaticians or analysts until getting a full agreement between all.

Archetypes usually have six stages in the management cycle. They are created if there is a clinicalneed, shared in a web based repository, reused on a different templates templates among various EHRsystems, specialized in case of a specific clinical need (e. g. weight to child-weigh), revised in case ofa error found on the archetype that needs to be corrected and updated, and versioned when the corearchetype (root archetype) is having flaws and needs to be remodeled. (Leslie and Heard, 2006)

3.5 Identifying parameters of new versions of archetypes

OpenEHR has dedicated a section that takes care of versioning of archetypes and templates, called theArchetype Object Model (AOM), a package inside on the AM. In this section will be explained how thispackage works and what are the inherited parameters from another packages in the OpenEHR ReferenceModel, which and what are the parameters for version controlling and how to identify in a human andmachine readable way the identification of each archetype, associated to his governance and life cycle.

3.5.1 The Archetype Object Model (AOM)

The AOM is a programming object from Archetype Model (AM) (OpenEHR, 2018f), that containsall the variables and parameters related with archetype and template identification, such as archetypespecialization, authoring of archetypes, version numbering and respective modifications. Currently, itgoes in version 2, after being renamed from version 1.5 and includes extensions made from the version1.4 of the ADL, like meta-data, new internal coding system, terminologies addition and many others.

These archetypes parameters are under the ARCHETYPE_HRID and AUTHORED_ARCHETYPEclasses (that has inherited classes and parameters from the RESOURCE package), which can be seenthe figure 3.4, represented by a Logical Data Model (LDM) for the AM package. Archetypes have twoways defined to be understood by machines or by humans (OpenEHR, 2018e). The human way is calledHuman readable Identifier (HRID), which consists on an identification structure that is defined by theARCHETYPE_HRID class. Inside of this class, there are parameters defined for each part of the ”full”archetype name.

Study I - openEHR CKM 48

Figure 3.4: am.aom2.archetype Package (from openEHR Archetype specification (OpenEHR, 2018f))

49 Study I - openEHR CKM

The archetype name can be sorted in two ways, one by semantic_id, which contains the extensionof version status and the build_count, that shows the development status of that archetype, or by thephysical_id, which is the formal aspect of an released archetype. This structures are composed by:

Structure for semantic_id:namespace::rm_publisher-model_name- rm_class.concept_id.v.major_version.minor_version.patch_version-

version_status.build_count

• Case example:

– org.openehr::openEHR-EHR-OBSERVATION.blood_pressure.v1.0.5-rc.17– org.openehr::openEHR-EHR-OBSERVATION.blood_pressure.v1.0.5-alpha

Structure for physical_id:namespace::rm_publisher-model_name- rm_class.concept_id.v.major_version.minor_version.patch_version

• Case example:

– org.openehr::openEHR-EHR-OBSERVATION.blood_pressure.v1.0.5

If dividing all the parameters from the semantic_id, to match each parameter inside of the ARCHETYPE_HRIDclass, they can be filled up as:

• namespace: org.openehr• rm_publisher: openEHR• model_name: EHR• rm_class: OBSERVATION• concept_id: blood_pressure• release version: 1.0.5

– major_version: 1

– minor_version: 0

– patch_version: 5

• extension:

– version_status: ”rc” or ”alpha”

– build_count: 17

The junction of each one of these parameters lead to the full identification of the archetype in a humanreadable way. The machine readable way is composed by the MD5-CAM, archetype_uid and build_uid.Is possible to affirm that ”ARCHETYPE.archetype_id.semantic_id” is the equivalent readable humanway of the ”ARCHETYPE.uid”, a machine identifier (OpenEHR, 2018e).

Study I - openEHR CKM 50

3.5.1.1 Version numbering

In the specifications for archetype versioning and identification (OpenEHR, 2018e), the ”revision” pa-rameter has special rules for the numbering identification based on semVer standard. The first three levelson numbering are identified by dot-separated numeric parts (majorVersion.minorVersion.pathVersion).

The majorVersion is incremented when there is a major and significant change to the artifact formaldefinition. This significant change can be the removal of mandatory data points or groups, removal ofnodes (also known as paths), move of those nodes to different sub-tree or the change of domain definitionof id-code.

The minorVersion is characterized by a lesser change, such as changes in the constraints, includingnode RM types, additional definition nodes (e.g. new paths) or the addition of terminology bindings.

In the case of patchVersion, this is incremented each time there is an informal change of the archetypeformal definition, like changes to meta-data, addition of language translations, changes to wording ofterminology that does not affect the sense of the definition or when the archetype is rejected. (OpenEHR,2018d)

These three levels can be identified as ”release_version” and this identifier can have added an ex-tension including the versionModifier.issueNumber, which gives the information about the ”lifecyclestatus” and the current build number / issue number. The lifecycle status can be composed by an alphaelement, seen as ”-alpha”, for an ”under development” or ”unstable” archetype, and a ”release candidate”(”-rc”) for a archetype with a pre-release version.

For example, it is possible to have two different types of revision parameters based on the previousexplanation:

• 1.1.1-rc.12 , translated from (release_version-description.lifecycle_state.build_count) and it meansthat has a 3 part version identifier and is a release candidate with the build_count of 12, which isincremented in every commit.

• 1.1.0-alpha , translated as (release_version- description.lifecycle_state) and is an archetype witha alpha development version based on 1.1.0 version.

An example of a archetype life cycle containing the release_version-description.lifecycle_state can be:

1.1.5-rc.1 < 1.1.5-rc.2 < 1.1.5 < 1.1.6-alpha < 1.2.0-alpha < ... < 1.2.0

The major version is reflected on the HRID source identifier, by ending the ”archetype_id” (e.g.openEHR-EHR-OBSERVATION.blood_pressure.v1) with ”v.X”, being X the value from the majorVer-sion.

In the first version of the archetype, the majorVersion always starts with zero, having the ”revision”parameters as (0.0.1). The identification name for an archetype with these parameters is ”openEHR-EHR-OBSERVATION.blood_pressure.v0” (RM_publisher-RM_closure-RM_class-concept_id.vX).

51 Study I - openEHR CKM

The lifecycle status have specials names to map the classification of an archetype:

Table 3.2: Archetype lifecycle mapping (XML format)

aom_lifecycle_mappings = <

[ ”AuthorDraft” ] = <”unmanaged”>

[ ”Draft” ] = <”in_development”>

[ ”TeamReview” ] = <”in_development”>

[ ”Team␣Review” ] = <”in_development”>

[ ”ReviewSuspended” ] = <”in_development”>

[ ”Review␣Suspended” ] = <”in_development”>

[ ” Reassess ” ] = <” published ”>

[ ”Published” ] = <” published ”>

[ ”Rejected” ] = <” re jected ”>

>

The previous table maps all the names found inside of archetypes content to describe the lifecyclestage.

3.5.1.2 Versioning parameters inside of ADL files

An EHR based on openEHR can digitally sign every version of an artifact in a versioned object (e.g.encounters). These artifacts are signed with a digital signature, composed by a private key encryption(RSA) of a hash (MD5) from the canonical representation of that versioned file (e.g. XML schema), usingthe openPGP message format.

When the artifacts undergo updates, these acts are called contributions. Each contribution is thenmarked inside of the archetype with an attributed identification and integrity parameters mentionedabove (MD5-CAM, build_UID), that allows for each archetype to have a unique way to be managedin case of further changes. These parameters are based on cryptographic hash algorithms, which aimis to transform one input of variable size in an output of lesser and fixed size. For example, all theinformation of an archetype can be inserted in a hash like “7341F7E8A07ACE883A5F541BA79F2B95”.These algorithms are non-injective functions and the output identification of each of them can not beunequivocal. That means that some messages can have the same hash string and if they have the samehash, the input message should be equal on both, but it should not be possible to retrieve the originalmessage by decrypting that hash.

Relating this with the openEHR artifacts, an archetype with the same hash value of the item ”MD5-CAM 1.0.1” should have the same information in the XML and ADL body. The identification parametersfor the openEHR archetypes are shown in the table 3.3.

Study I - openEHR CKM 52

Table 3.3: Excerpt from blood pressure archetype (XML and ADL format)

XML:( . . . )

<uid><value>b1506a87−9bf2−4978−9eed−6ceecb0c2be9</value>

</uid><archetype_id>

<value>openEHR−EHR−OBSERVATION. blood_pressure . v1</value></archetype_id>

<adl_version>1.4</adl_version>( . . . )

<l i f e c y c l e _ s t a t e>published</ l i f e c y c l e _ s t a t e>( . . . )

<other_detai ls id=”original_namespace”>org . openehr</ other_detai ls><other_detai ls id=” or ig inal_publ i sher ”>openEHR Foundation</ other_detai ls><other_detai ls id=”custodian_namespace”>org . openehr</ other_detai ls><other_detai ls id=”MD5−CAM−1.0.1”>7341F7E8A07ACE883A5F541BA79F2B95</ other_detai ls><other_detai ls id=”build_uid”>68040aab−98da−4b3c−a93c−c91df19b05f8</ other_detai ls><other_detai ls id=” rev i s i on ”>1 .1 .1</ other_detai ls>

( . . . )

ADL:archetype ( adl_version =1.4; uid=b1506a87−9bf2−4978−9eed−6ceecb0c2be9 )openEHR−EHR−OBSERVATION. blood_pressure . v1( . . . )

l i f e c y c l e _ s t a t e = <” published ”>( . . . )other_detai ls = <

[ ”original_namespace” ] = <”org . openehr”>[ ” or ig inal_publ i sher ” ] = <”openEHR␣Foundation”>[ ”custodian_namespace” ] = <”org . openehr”>[ ”MD5−CAM−1.0.1” ] = <”7341F7E8A07ACE883A5F541BA79F2B95”>[ ”build_uid” ] = <”68040aab−98da−4b3c−a93c−c91df19b05f8 ”>[ ” rev i s i on ” ] = <” 1 .1 .1 ”>

>( . . . )

These parameters are under the ”other_details” section and each one has a different content:

• ”archetype_id” which contains the information about the archetype name, including the majorversion, for example ”blood pressure” is defined as “openEHR-EHR-OBSERVATION.blood_pressure.v1”,where v1 is the major version of this archetype.

• “original_namespace” refers the name of the organization that has originally been developingthe archetype.

• “custodian_namespace” is used to refer the organization that is currently taking care of thearchetype. It can changes from time to time in case of adoption from another organization.

• “original_publisher” identifies who were the responsible of publishing the archetype for the firsttime.

• “revision” (e.g. “1.1.1”), based on the semantic versioning from semVer.• “lifecycle_state” which gives the stage of different lifecycles associated to the archetype devel-

opment (e.g. “published”).• “uid” is the unique identification number for each archetype. For example, the ”blood pressure”

archetype will always have the UID “b1506a87-9bf2- 4978-9eed-6ceecb0c2be9”, even if the versionof the archetype was changed. The format is made by an Universally Unique identifier (UUID), anidentifier that is unique across both space and time.

• “build_uid” - Every time the archetype get a new change or version and is uploaded or committedto some repository, it will get a new ”build_id”, which is unique for every build. The format is also

53 Study I - openEHR CKM

made by an UUID.• “Major Version UID” - When the majorVersion of the archetype changes (e.g. from v0 to v1)

the Major Version UID also changes. It has a format of a Secure Hash Algorithm (SHA).• “Canonical MD5 Hash” or “MD5-CAM-1.0.1” is a hash that is calculated by the actual values

inside of the archetype, which means that every new version with changes will have a different hashcode.

When an archetype is modified and gets a new version, the parameters that identify the versioning- “revision”, “build_id” and “MD5-CAM” - are also changed. In the image 3.5, which is related to theblood pressure archetype hosted on CKM international mirror at GitHub, the changes can be checkedwith the new values given to ”MD5-CAM”, ”Build UID” and ”revision”. Another example can be seen onfigure 3.6. The red color is identifying the old version of the archetype and the new version is identifiedwith green color.

Figure 3.5: Values of archetype identification parameters modified after changes.

Figure 3.6: Changing the archetype provokes modification on the MD5-CAM-1.0.1 hash

Some of these parameters, such as the ”archetype_UID”, ”Build_UID” and ”Canonical MD5 Hash”will be used to identify the new versions of archetypes in both repositories (international CKM and alocal CKM) in the implementation and methodology chapters.

Important note: the cryptographic algorithms currently used to transform the archetypes identifi-cation and body into a hash string have already been broken by collisions attacks. This means that thereis probability of an archetype to present the same hash of another different archetype, although there isa very small possibility to happen (Selinger, 2006).

Study I - openEHR CKM 54

3.6 Current outcomes from openEHR artifacts usage

One of the aims of openEHR was to provide public archetypes in a single international repository(openEHR CKM), after being agreed by the international online community, that could be used in severalEHR systems around the globe. It is also possible to add regional or local archetypes that would stillbe compatible with the previous ones inserted in the international CKM (using CKM incubator feature)and making the information shareable with everybody. However, the current use of archetypes are notworking in this way (Grieve, 2016).

Some of them are using the international CKM and being compliant with it, others are not. Otherprojects have initially downloaded the archetypes from international CKM, but made a few changes tocomply to specification requirements (see section 1.3.5.2) and then saved on local repositories like GitHub,GitLab, SubVersion or Preforce. This results in a jumble of archetypes variations from the internationalbase of these archetypes, which was not the aim from openEHR.

3.7 Structure of openEHR Foundation International CKM Mir-ror on GitHub

To maintain a copy of every artifact created on the openEHR CKM repository, the openEHR Foun-dation made a mirror from the international CKM and hosted it on GitHub. This mirror contains all thearchetypes, templates and termsets from the CKM “Authoring TRUNK”, including the published andunpublished/unstable artifacts that keep going under active development and review. If the “AuthoringTRUNK” from CKM changes, this behavior it is automatically replicated by this mirror repository onGitHub.

The figure 3.7, presented in the next page, shows that currently the OpenEHR International CKMstructure are divided in two main groups in the same blob (master): local and remote. The localgroup refers to all the artifacts (archetypes, templates and termsets) contained on the openEHR CKM(org.openehr) that were made and reviewed by the online community. The remote group refers to theother instances from CKM (Nehta, Nasjonalikt and UK Clinical Models) that have artifacts submittedto the main CKM, but still authored by them. Commonly the main CKM is the most complete of all theinstances created after it.

55 Study I - openEHR CKM

Figure 3.7: Structure of openEHR CKM mirror on GitHub (May 2018)

Study I - openEHR CKM 56

Study II - Life cycles of ar facts

59 Study II - Life cycles of archetypes and templates

4. Study II - Life cycles of archetypesand templates

Since the start of openEHR CKM operation, a huge percentage of archetypes have been created. Manycontributors have developed them around the world (OpenEHR, 2018c). With this, a lot of changes canbe made to the root lining, and to not allow a divergence in the content of each created archetype, theopenEHR CKM group defined rules and methodologies for the archetype development process, commonlycalled Archetype Development Life Cycle (ADLC) (Maria Madsen, 2010), which is based on the SoftwareDevelopment Life Cycle (SDLC). This process will be explained in detail in this chapter.

4.1 The Archetype Development Process

The process of an archetype development process can be divided in different phases. It starts withthe identification of clinical requirements, search if compatible or reusable archetypes already exists inthe openEHR CKM and if not, it will require the creation of the desired archetype, normally followedby a submission to the openEHR CKM repository, where a process of archetype review by the openEHRreviewing team will be made. In case of common consensus from the reviewing editors of the CKMrepository included on the review session, the archetype will be published. Inside of all these steps,there are other sub-processes that needs to be done. M. Madsen et al in 2010 proposed the phases of aniterative archetype development process. Others proposals have been made lately too, but based on thesame process (Hammond et al., 2014), (Min et al., 2018). They are composed by:

1. Planning phase - containing the content gathering and clinical engagement;2. Analysis phase - data analysis and consolidation, draft modeling estimate and knowledge of

current available archetypes;3. Requirements specification phase - where are presented the clarifications of content questions

and other issues with end users and start of a modeling plan creation;4. Design phase - including the archetype design (Beale and Heard, 2007a), creation of clinical

models and the addition of terminology;5. Testing, evaluation and review phase - review of interactions between content and terminology

and modeling review;6. Delivery phase - model sign-off and hand over to vendor;7. Maintenance phase - fixing small issues that can appear and giving correction updates if required.

Study II - Life cycles of archetypes and templates 60

In the first phase of the development process is necessary to define essential procedures for analysisand choose a work group (project manager, a clinical expert/ physician, terminology and technical expertand an openEHR modeler) (Moner et al., 2018). Usually, this is the crucial point that will allow to donot waste time and money on reviewing all the procedures in every step of development, in case of wronginitial analysis.

When making an initial data analysis, is mandatory to understand and determine all the necessaryinitial requirements, data collection and content gathering. This can be done by analyzing the manypossible sources, like the paper based forms used on the health care institutions by the physicians, un-derstanding how the work flow is processed in these institutions and which guidelines have been used. Toidentify the different clinical concepts, the creation of a mind-map could help to visualize the gathereddata during this process stage (Marcos and Martínez-Salvador, 2010). Also, checking how the existingelectronic health records present the forms and the information stored on their databases can be a usefulhelp. All the collected information along with a good data analysis processing, can result in a archetypethat will be fitting the main purpose. Nevertheless, including all the external parties and end-users in-volved in the process to have basic training on the openEHR methodology should optimize the contentgathering process.

When the first step is almost concluded, is necessary to start a modeling process plan, which allows tohave an idea of what the next process of archetype development will look like. It is always vital to havecollaborative meetings to discuss the development process with end-users (health professionals), clinicalmodelers (e.g. health informatician), IT technicians and external parties that will be using the artifacts.This will allow to check if the requirements are being met, such as, the verification of the archetypes andtemplates that are under development, are aligned with the final user requirements and then maximizingthe interoperability between the systems that will make use of these artifacts. One of the aims is to max-imize the re-usage of each archetype created. Along with this, is time to start to prepare terminology,standards implementation, work flow and Graphical User Interface (GUI) design to be used on production.

During the second phase, is necessary to analyze and make a consolidation of the data gathered in thefirst stage. This should be done by a health informatician to identify issues in the process and contactdirectly with the physicians to solve the problems in a accurate and correct way. In this phase, a fullanalysis of existing archetypes should also be made. A search should be made to check if there are al-ready archetypes on the international openEHR CKM that fulfill the requirements or, if not, create newarchetypes or improve the existing ones. Having a wide knowledge of already existing archetypes can savea lot of effort and time in this phase and the openEHR CKM works in a way to avoid the duplication ofarchetypes.

For the requirements specification phase, possible content issues should be determined with all techni-cal modelers, User Experience (UX) experts, vendors and terminologists, and questions about the contentshould be clarified among the implementation team and the end users in an constant interaction. Thisspecifications should reflect the real world on practice (Hovenga and Grain, 2013) and the communicationbetween all the working team is the key for success. In the design phase, also known as the archetype

61 Study II - Life cycles of archetypes and templates

design phase (Maria Madsen, 2010) (Beale and Heard, 2007a) the primary creation should be conductedby physicians, since the structure and language used should reflect the environment of the main user ofthose resources. In this phase, is when the archetype start to be created by the technical modeler, aftergathering all the content to be used within, in case of not finding an archetype that can be reused orspecialized from the openEHR CKM. It starts with identification of the purpose of this archetype, thedata elements to be included and the terminologies to be implemented. Then, the classification of thearchetype should be done, for example, if the RM class of the desired archetype will be a instruction,action, observation or evaluation, and the archetype name is defined, along with the structure, datatypes, constrains, metadata and the terminology mentioned previously added to the different items. Theresearch made on specific articles to implement this archetype should be prepared and included. Theaddition of terminology, interface and modeling should be also done along this creation to maximize thedevelopment time and aim fitting.

Other very important stage is the testing, evaluation and review phase, where all the previous pro-cesses will be approved or not, after consensus from all the participants involved. During this phase, theend users should obligatorily receive a preparatory introduction and training to the openEHR modeling, ifit was not made previously, to learn how to the archetypes and templates work in order to help to improvethe content from those artifacts, including the terminology used. The archetype modeling should also bereviewed in this phase, since each technical modeler have his own way to create different structures. Thisshould include verification of all the archetype information present on the concept name, description,keywords, propose and use or misuse of the archetypes reviewed. Also, a comparison with other similarmodeling standards should be done and feedback retrieved, for example from FHIR or HL7. When thereis a consensus from all the team and everything is aligned from all the working groups parts, this meansthe archetypes lifecycle can be changed to ”published” and the delivery phase can start, which meansthat the vendors who are implementing these clinical models on their EHR systems, can have access tothe repository of clinical models or openEHR artifacts, like the openEHR CKM, for example.

Figure 4.1: Phases of archetype creation, using the example of openEHR CKM as a clinical modelsrepository

Study II - Life cycles of archetypes and templates 62

Like all the others IT development projects, the final stage is the maintenance. After an archetype hasbeen published, it is necessary to support it and continue to provide a continuous improvement on thatartifact. There are many reasons to keep maintenance, for instance, more additions could be implementedto the archetype that may reply to more specifications or requests from the vendors or the end users,some errors or bugs could be found and need to be quickly solved, or could even been necessary to makea specialization using the parent archetype. Also after the publication is made, the archetype lifecyclephase can constantly change. If this archetype gets a major or better version, it can be replaced, turninginto an obsolete archetype.

It is really necessary that all these procedures should be carefully prepared with usual meetings withhealthcare, IT and technical professionals to make sure that the final aim will be compliant with everyside. Otherwise, it can result in a creation of an archetype that does not met the specifications andturn on a waste of time by not being accepted on the openEHR CKM and turns up being used onlyinternally. Also, if it is possible to always send an English version of the submitted archetype, along withthe translations of other languages, this could improve the time of revision, since the bigger part of theopenEHR editor are English speakers.

For template creation, it does not need to have the same amount of work and preparation to getspecific requirements and further development, comparing with the case of the archetype, since it is onlyan aggregation of a set of archetypes.

In the figure 4.2 in the next page, is possible to see the diagram made by the openEHR team (Leslie,2008) that currently takes care of the openEHR artifacts governance under the international CKM. Thedifferent archetype lifecycles are represented by the yellow boxes (draft, team review, published and ob-solete) and those divide the different procedures made within each phase.

63 Study II - Life cycles of archetypes and templates

Figure 4.2: Archetype authoring, review and publication (Leslie, 2008)

4.2 Distributed governance of archetypes

The creation of an archetype usually starts when a need is found or a request is made, which willrequire an openEHR modeler to start constructing it on his own computer alone or with a team, forsome project. This means that this archetype will have no custodial organization (e.g. au.gov.nehta,uk.org.clinicalmodels or org.openehr) managing it, getting the v0 version according to the semVer rules,and the life cycle identifies it as ”unmanaged” - this cycle does not exist on the openEHR CKM(OpenEHR, 2018a).

After following all the steps described in the previous sub-chapter, when the archetype is done andprepared to be submitted to some CKM instance, it needs an approval from the custodian organization

Study II - Life cycles of archetypes and templates 64

that manages that instance. After being submitted and accepted by the custodian organization, itgets this custodian name in the ARCHETYPE HRID namespace, e.g. org.openehr::openEHR-EHR-OBSERVATION.blood_pressure.v1.adl and a new meta-data parameter within the archetype is filledas e.g. [”custodian_namespace”] = <”org.openehr”> along with a new UUID, license and copyright.Relatively to the versioning number, the major version is reset to 0 and the other versioning parameters(minor version and path) to 0.0.1.

Figure 4.3: Development Lifecycle with Versioning (OpenEHR, 2018b)

Although an artifact can be accepted by a custodian organization, if this resource does not get anactive maintenance, it can be rejected or migrated to another custodian organization. When this happens,the new custodian organization is allowed to make some changes on the archetype identification (humanor machine readable way) under certain rules.

In case of the human readable way, the namespace can change to include the new organization, theconcept_id (e.g. blood_pressure) can also change depending on the new custodian requirements andthe versioning parameter is usually changed to 0 (0.0.1). Since the human readable identifier (HRID) ischanged, its uid will be changed also to a new one, in conformity to the new name.

Inside of the archetype content, there is a section to show the management history of an archetype,that is being transfered between different custodian organizations as it can be seen in table 4.1:

65 Study II - Life cycles of archetypes and templates

Table 4.1: Archetype custodian organization history (OpenEHR, 2018a)

id_history = <[ ”2001−05−27” ] = <

old = <hrid = <”au .com. rbh::openEHR−EHR−EVALUATION. problem_desc . v2 . 4 . 1 ”>uid = <”5221C9E5−0ECA−469F−83C5−A5D5A0C6682C”>

>new = <

hrid = <”au . gov . nehta::openEHR−EHR−EVALUATION. problem . v1 . 0 . 1 ”>uid = <”094C8B37−F0CD−45C9−A1B7−CDFDE14C67AB”>

>>

Study II - Life cycles of archetypes and templates 66

4.3 Governance of a local repository based on openEHR arti-facts

This section presents a recommendation by the author. The available information about this topic onscientific jornals or articles is minimal or almost inexistent and not directed to the openEHR artifacts,but to software coding in general.

When new EHR project based on openEHR standards have concluded the specifications and require-ments phase and it is already prepared to get the development phase for the artifacts, the gatheredinformation needs to be stored and always updated when necessary. The openEHR resources are notstatical, a lot of new updates are made constantly to improve the knowledge saved and retrieved fromthem. The best way is to construct a local CKM repository, that needs to be compliant with the openEHRCKM, as explained in the previous chapters.

Maintaining a repository based on openEHR and compliant with the openEHR CKM can be hardand time consuming, if not wrought since the beginning of its creation. Sometimes different modelers oreven programmers, created and changed the archetypes in such a away, that is complicated to have anew person to be on charge of taking care of the repository. If this repository is not managed in a wayto carefully take care of the content and all the changes made to these resources, which are what keepand structure the most important part of an EHR system, the health data, the repository can end up ina imbroglio of misleading data structures.

For that, the following steps should help to maintain, in a better way, the management of a localCKM:

1. Choose a person responsible to create and maintain the local CKM repository. A person with abackground in both engineering or informatics and health care and that have study the openEHRspecification, suits the best. A ”backup” responsible person can also be a good choice in order nothave all the repository knowledge imprisoned to just one person.

2. When creating a new CKM repository to store the openEHR artifacts that have been downloadedfrom the openEHR CKM, a good practice is to use one that supports CVS and is hosted online. Asa personal choice, if the enterprise or company where the project that will depend from artifactshas a GitLab instance, use that instance, if not, use GitHub. Both are free to use and offer a goodsupport. Hereupon is possible to maintain a creation and edition history of those artifacts. If thereare archetypes saved on a local computer that are being used on current projects, but not availableonline, that knowledge can be easily lost. Apache SubVersion (SVN) based repositories are alsocomplicated to maintain on large projects, so it should not be a valid choice.

3. Choose an openEHR archetype and template editor. As a personal choice, the ADL Designer web-tool is user-friendly, free to use and is the most supported openEHR modeling tool nowadays. Also,it offers connection to the local repositories and commit the changes made to them.

4. The responsible person should be on charge of making weekly verification updates from the local

67 Study II - Life cycles of archetypes and templates

openEHR resources with the ones available from the openEHR CKM. Using the script created fromthis dissertation can help (note: only if the local repository is connected to the ADL Designer tool).

5. In case of finding an archetype that needs to be updated, prepare time to check and change all thetemplates that also make use of this resource. Sometimes adding terminology to the template needsto be done again, among others many others changes.

6. The responsible person of the local repository should have an active testing of the forms used withinthe developing project. An error related with archetypes may arise and since the responsible hasopenEHR experience, he would know how to solve it quickly. Also, all the existent combinationsthat can be done on the form should be tested before deployment, and this can be time consuming.If a bug is found due to a mistake on the archetype logic, report it immediately to the openEHRCKM page, for correction and further update. It is important to remember that these archetypeslive through an active community that works for free to correct some bugs in these artifacts. Do notforget that a bug in the archetype of your project will also exist in other projects that are using thesame archetype. Communication and reporting is the golden standard for local and internationalimprovement of the openEHR standard.

7. If a new requirement needs the building a new archetype, search if there is some created resourcesin the openEHR CKM. Use specific keywords to search your subject, choose the archetype and readthe associated header along with the use and misuse of this resource. A lot of new archetypes arecreated inside of local repositories due to a poor search on openEHR CKM. If the openEHR CKMhas your topic, but does not include everything you want, suggest a new review to include yourcontent, or specialize the one you want. Nevertheless, send your new archetype for review on theopenEHR CKM. A lot of content is being created and reviewed, and new clinical content to enrichthis platform is always welcome.

8. If you create a new archetype to fit local requirements, do not name it with the same name as theother archetypes on openEHR CKM and use a correct lifecycle and versioning for the process ofarchetype creation. OpenEHR has very well defined parameters of how to deal with this topic thatwere mentioned in the previous chapters.

Following these steps, can help to lead on good governance of the openEHR resources from the localCKM repositories. But this just depends on how the company and the project manager on charge knowsthe value of having this data knowledge updated and put on charge a person responsible for this task.

A lot of projects that does not have any governance of their repositories, ended up with a jumble ofinformation on their databases, which is almost impossible to correct in a proper way, due to the timeconsumption that this task can be. If the local CKM repository is created and maintained in a properway since the begging, the constant updating of resources would take between one to two hours per weekfor correction, or even less, depending on how much templates are connected to the updated archetypesor if it has a higher number of terminology sets to be inserted.

A local repository should be governed in the same way as the openEHR CKM, with strictly governedarchetypes and in a constant sharing with the international CKM instance.

Study II - Life cycles of archetypes and templates 68

Material and Methods

71 Material and Methods

5. Material and Methods

In this chapter will be presented the materials and respective methods used to develop the script,including the system architecture, user stories and use cases. Also, an analysis of the provided repositorywas done, for comparison of compliant archetypes between the local repository and the internationalCKM.

The provided local repository with artifacts was hosted at GitLab. Is a private repository that needsauthentication to access the information inside of it. The REST API provided by this service was inversion v4. The comparison repository (openEHR CKM) is publicly accessible and is hosted on GitHub.A REST API is also provided by this service and authentication is not necessary to access to repositoriescontent. This repository is a mirror of all the content posted at http://www.openehr.org/ckm/. To testthe REST API calls in both repositories was used Postman, which is a tool for prototyping and testingHTTP API’s with a lot of testing features and with user friendly GUI. To get archetypes from repositoriesand expose them in a create and edit environment, was used ADLDesigner and some REST API callsfrom it, that will be explained in more detail bellow. The script will run along with this web tool, sinceit is dependent from its REST API calls to GitLab repository and require the same credentials to login and retrieve the hosted archetypes and templates list. For script development was used the VisualStudio Editor from Microsoft and the code for the script was written in Angular 2/Typescript, a variantfrom Javascript. To host it as a live demo, was used StackBlitz, an online IDE for web applications thatis powered by Visual Studio Code (Microsoft) and it is free to use. Moreover, for algorithms flowchart,UML and use cases, was used Camunda Modeler, StarUML and Visual Paradigm.

List of links of software used and repositories:

• Internal/local repository: https://gitlab.marand.si/ThinkRegistry/achf/ckm

• openEHR international CKM GitHub mirror repository: https://github.com/openEHR/

CKM-mirror

• Postman: https://www.getpostman.com/

• ADL Designer: https://ehrscape.marand.si/designerv2/#/designer/login (web tool), https:

//github.com/openEHR/adl-designer (source code)• Visual Studio Code: https://code.visualstudio.com/

• Angular 2: https://angular.io/

• TypeScript: http://www.typescriptlang.org/

• StarUML: http://staruml.io/

Material and Methods 72

• Camunda Modeler: https://camunda.com/products/modeler/

• Visual Paradigm online: https://online.visual-paradigm.com/

• StackBlitz: https://stackblitz.com/

• Tortoise SVN: https://tortoisesvn.net/

5.1 Analysis of archetype content from local repository and com-parison with openEHR CKM repository

Before starting developing the script, an analysis of the provided repository was made. This analysisconsisted on a direct comparison between the version, versioning parameters and content of archetypesinside of this local repository in GitLab with the archetypes from the international openEHR CKM hostedon GitHub. The local repository had 41 archetypes and the primary search was made by archetype nameon both repositories. For each one of these archetypes was given a status to define the conformity withopenEHR CKM:

• ”Outdated” in case of versioning parameters (Major Version, revision, archetype UID, MD5-CAM)and content inside of the archetype being different in both repositories;

• ”Not found”, if the archetype in the local repository was totally changed by another one on theinternational openEHR CKM, but with similar content, or even if this archetype does not existanymore on the international CKM - case of archetype specializations that lost connection with theparent archetype;

• ”Internal”, which is the case of creation of new archetypes that needs to meet certain clinicalneeds and are not present on the international CKM or when they are specialized to meet somelocal or national requirement;

• ”Compliant”, when the archetype has the same versioning parameters (Major Version, revision,archetype UID, MD5-CAM) and content are similar in both repositories, which means that has thelatest version from the international CKM;

It was expected to have some outdated archetypes during the analysis, since it is a normal behaviorin developing area - with time changes are made and bugs can be found. In the next table is possibleto see the results of this comparison between both repositories. The full analysis can be checked in theannexe 1 from chapter 12 of this dissertation.

Table 5.1: Summary of archetype comparison analysis from the provided CKM repository with GitHubmirror of openEHR international CKM - all the versioning parameters (June 2018) (n=41)

Total (n=41)Archetype Status n (%)

Outdated 12 (29,27)Internal 16 (39,02)Not found 3 (7,32)Compliant 10 (24,39)

Although it is a repository with a high percentage of internal archetypes due to local or national

73 Material and Methods

requirements, which are not present in the international CKM, a lot of archetypes are outdated too.Some of them were downloaded to the local repository in November 2016 and since that date, therewas no verification of new versions of archetypes from the international CKM. This can result in errorsthat can still exist in the local repository, that most probably were fixed on the international CKM, oreven additional content that would enrich the local archetypes. Also, having a repository with thesecharacteristics is not the aim of openEHR ideals, where less than 1

4 of the artifacts are compliant withthe international CKM. To manually verify same archetypes on both repositories, side by side and checkall the content and versioning parameters took around nine hours to complete.

5.1.1 Other Findings between analyzed repositories

During the analysis of both repositories, some not expected issues have been found, that compromisethe correct versioning of those resources due to some error or bug during the implementation management.

• From local repository:

– Archetypes with the same content, but with different MD5 hash. Those can be due to someerror from previous versions of ADL Designer, where this resources have been modeled or bysome hand-made change to the archetype on a text editor and then uploaded it again to thelocal CKM.

– Some of the updated archetypes presented minor changes that did not include any change onthe MD5 hash parameter, which should not happen. If there is a change in the archetype,even by one character, the MD5 hash should change, since it is created from all the contentinside of the archetype.

– Archetypes that have been codified with build_uuid instead of build_uid in the local repos-itory, probably due to some implementation on ADL Designer, for example, the case ofopenEHR-EHR-OBSERVATION.body_weigh archetype.

• From openEHR CKM mirror at GitHub:

– Archetypes that exists on openEHR CKM, but are not mirrored to the GitHub repository, e.g.:openEHR-EHR-CLUSTER.address_isa and openEHR-EHR-CLUSTER.healthcare_provider_parent.

– Case of archetypes that have been renamed and lost connection to the previous resource,although they still have the same content and versioning parameters, e.g.: openEHR-EHR-CLUSTER.timing_nondaily and the previous openEHR-EHR-CLUSTER.timing_repetition,or the case of the openEHR-EHR-OBSERVATION.indirect_oximetry, with the previous nameopenEHR-EHR-OBSERVATION.pulse_oximetry. Since that change of the archetype nameprovokes a change on the achetype UID, it is complicated for a repository manager to followthe changes made, since the tracking from these archetypes is lost when the UID is changed.If the manager is not checking constantly the openEHR CKM news or the openEHR CKMtwitter account, it is tricky and even more time consuming to know what changed and when.

– Archetypes that are specialized from other archetypes (parents) and the those archetypes havebeen updated to newer versions or deleted from the repository, which make the connectionbetween them lost.

Material and Methods 74

5.2 Software Engineering

When designing any type of software, it is necessary to know what are the requirements and needsfor correct implementation. Making an user story and a use case of what will be developed in thisdissertation, can help to understand it in a much better way. These two approaches contain a set ofnarratives of real situations inside of the problem domain and describe the work flow in the perspectiveof one or more users of the system.

5.2.1 User story and use case

A simple example of an use case can be described by an application for medication prescription thatis being developed. This application can be used by the physician and patient, where the physician hasthe possibility to choose instructions that can be sent to the patient, with information about how themedication should be taken and how many times per day it should be done.

For this, an archetype to define ”daily timing” with the times per day (or day parts) was downloadedin December 2017 from the international CKM to the local repository where the application is beingdeveloped. This archetype was updated on the international openEHR CKM in January 2018 to correcta mistake on the ”magnitude” parameter, that defines and counts how many times per day exists. Forexample, a day can be divided by morning, moon, afternoon and evening and the sum of all of theseevents is four, which means that the magnitude value should be at least four. On the outdated archetypeADL that was being used inside of the application under development, the magnitude was defined as”<|0.0..1.0|>”, that means the occurrence value can only be 0 or 1.

Because of this, when the information was inserted in the form by the user (physician) and sent tothe server, with more than one day part per day, the archetype logic did not accept that value and itautomatically threw an error describing that the added value was not supported. The updated archetype,had defined for magnitude ”<|>=1.0|>”, which means bigger or equal than 1. This means that thisoutdated archetype needs to be urgently substituted by the new version on the local repository. In thefigure 5.1 can be seen the error threw by the EHR server for the archetype magnitude item, when theparts per day were bigger than one.

Figure 5.1: Server error on a under development application by wrong archetype logic (Outdatedarchetype on local repository)

75 Material and Methods

If an experienced openEHR clinical modeler is used to these type of errors, it can be corrected quickly.Usually, if detected in a earlier stage by constant checking for updates on openEHR CKM, can save severaltime and money on projects.

After some analysis of the CKM repositories users, was defined that the usual user of the script toupdate the archetypes would be the person responsible for taking care of the governance of the localopenEHR artifacts repository on their respective project, role usually performed by a clinical modeler,health informatician or even a programmer (when access to the first two are not available). It starts withone of these users being the ”CKM repository owner”, creating an account on ADL Designer web tooland login on that application. After that, is necessary to create the desired repository connector andconnect it to the local repository, which can be from a local computer folder or from an online repository.After the account and repository were created, a login with the same credentials and repository id fromADL Designer needs to be inserted on the login section of the script page, and if the user is authenticatedsuccessful, the script will run the code and a table with a list of archetypes and templates from thatrepository will be presented. If there are updates, those will appear together in a column with the alertof an outdated or compliant archetype with the openEHR CKM mirror on GitHub, for each elementfrom those lists. A link that retrieve the actual archetype RAW form (ADL) from the openEHR CKMmirror on GitHub should be click-able. Then, if the user wants to download this new archetype to hiscomputer, he can use a tool for comparison like Tortoise SVN, that will show the difference between thenew archetype and the old archetype hosted in the local repository. This part needs to be done manuallyby the user.

Figure 5.2: Use case scenario

Material and Methods 76

5.3 ADL Designer

ADL Designer is a open source web based tool developed by Marand d.o.o. for implementation ofmodeling tools used in development of openEHR artifacts. Is mostly written on JAVA and JavaScript,with a web interface based on jQuery and Bootstrap 3 frameworks. It has full compatibility with theOET files from the previous openEHR tools by Ocean Informatics and also to version 1.4 of archetypesand templates. Is composed by two main modules, the Archetype Editor and Template Editor.

For using this tool, is mandatory to have an account to login. Currently, it provides a free accessfor testing with a default ”test” account. After login, is necessary to add a web repository or a localfolder repository. One of the most interesting features from ADL Designer is that it can be connect toinumerous repositories hosted in different GIT providers, either online or local, such as GitHub, GitLab,Bitbucket, Dropbox, Google Drive, OneDrive or at a local GIT folder in a single computer, allowing thepossibility to work on top of each one of them. With this, is possible to edit archetypes and templatesfrom these repositories and directly save the changes made on the repositories again, having the historyof all these changes in one place and the possibility to rewind in case of sudden lost of files.

Figure 5.3: ADL Designer (Marand d.o.o.)

Also, it gives the option of exporting the content from the added repository and analyze the content,like retrieving the amount of normal and specialized archetypes, getting the information if some par-ent archetype that was used for specialization is missing from the repository, getting the list of clinicalterminologies bindings used on each archetype and by parsing them, it shows if there are misleading insome terms or constrains, or if RMtype slots are not filled on the respective templates. It is in constant

77 Material and Methods

development and will support new features in a near future.

The source code can be found at https://github.com/openEHR/adl-designer.

5.3.1 Archetype Editor

With this module is possible to edit, specialize, save, import and export archetypes in the ADL2version. It offers an improved and user friendly GUI comparing with all the other openEHR modelingtools and more exporting formats, such as OPT, OET, xmind (mindmap) and Fileset.

Figure 5.4: ADL Designer Archetype Editor - Web Interface (Marand d.o.o.)

Architecturally is composed by two different sub-modules, exposed on figure 5.5, one handled bythe browser that allows to see the interface of archetype editor with the help of the ”Archetype ObjectModel” (AOM) and the Reference Model (RM) packages. The AOM is a set of code packages which canbe used with archetype parsers and software to manipulate archetypes and it is independent from theweb interface.

Material and Methods 78

It has supported functionality from AOM package for various properties, such as (OpenEHR, 2016):

• AOM.ArchetypeModel - Wraps AOM of a single archetype, allowing for easier manipulation.It can also manipulate terminology, annotations, constraints, translations, bindings and specializedarchetypes;

• AOM.NodeId - models a single node_id, such as id1.1.3;• AOM.RmPath - models a single rm_path, such as /data[id3]/items[id4]/value;• AOM.AmQuery - enables searching for constraints that match a particular rm_path;• AOM.createNewArchetype - Create a new archetype from scratch, with a provided basic struc-

ture based on the Reference Model class;• AOM.ReferenceModel - Provides reflection-like functionality for a reference model.

The RM takes care of the handling of constrains data types packages, like classes for DV_DATE,DV_TEXT, DV_INTERVAL, DV_QUANTITY, DV_TIME and many more.

The other sub-model is handled by the web server, where the REST calls are being made to the repos-itories that have been previously connected to ADL Designer over the ”Archetype Repository” module.This module makes use of the ”adl2-core”, a reference implementation of openEHR reference model,archetype model, ADL and AOM2 semantics. Is based on a JAVA library and is the core of ADL2implementations of openEHR. For example, this will allow to parse all the archetypes.

Figure 5.5: ADL Designer Archetype Editor - Architecture (Marand d.o.o.)

The source code can be found at https://github.com/openEHR/adl2-core/.

79 Material and Methods

5.3.2 Template Editor

The template editor works in a similar way of Archetype Editor. It uses the same basis and function-ality with the two sub-models, browser and web-server, but with major changes on the browser side. Ithas one more functionality added to the AOM variable:

• AOM.TemplateModel, which models a template where is possible to add or remove archetypes.

All the other functionalities from AOM variable (ArchetypeModel, NodeId, RmPath, AmQuery, Ref-erenceModel) are inherited from the Archetype Editor model, mentioned previously.

Figure 5.6: ADL Designer Template Editor - Web Interface (Marand d.o.o.)

Some of the features that are possible to be done on this editor are: Adding annotations, makingchanges to the occurrences of some openEHR template paths, adding external terminology (for exam-ple from a URI) or adding local terminology, work on the desired language present on the compositionarchetype and in the archetypes added as a content in the main template.

Along with the ”Archetype Repository” module, it also has the ”Template Repository” modules in theweb server side, that make accesses by REST API calls to the repository where the content is allocatedand retrieves the list of templates. Besides that, it allows to load, edit and save the templates back tothat repository. In the figure 5.7 is possible to see the architecture model.

Material and Methods 80

Figure 5.7: ADL Designer Template Editor - Architecture (Marand d.o.o.)

5.4 Angular 2

Angular 2 is a open-source web application platform made by Google, that relies on front-end forbuilding client-side applications in Hyper Text Markup Language (HTML) and it is based on TypeScript(Google, 2018).

Is fully re-written from its predecessor, the Angular JS (JavaScript). The developed script fromthis dissertation was written using Angular 2 framework, since it can provide almost all the neededfunctionalities out of the box, like the HTTP client, that allows to interact with the REST API callsfrom both openEHR resources repositories and dependency injection, without having to worry withexternal libraries, since this framework bring a bigger part of them.

It is composed by modules, components, services and dependency injection. Angular allows to con-struct modular applications and it has also a modular system - the NgModule, which contains code forthe application domain and explain how the application parts fits together. It contains a decoratorcalled @NgModule, that has the metadata and properties to describe the module like: imports, providers,declarations, exports and bootstrap. These properties can be seen in table 7.1.

The components are what controls the view of what will appear on the screen. These components canbe created, updated or destroyed depending on the user movement through the application dependingon the lifecycle function chosen.

81 Material and Methods

Table 5.2: Example of NgModule and Component decorators at app.module.ts and app.component.ts filesfrom the developed script.

##################### app . module . t s #####################

import { BrowserModule } from ’ @angular/platform−browser ’ ;import { NgModule } from ’ @angular/core ’ ;import { HttpClientModule } from ’ @angular/common/http ’ ;import { getArchetypesFromADL } from ’ ./ app . s e rv i c e ’import { AppComponent } from ’ ./ app . component ’ ;

@NgModule({

dec l a ra t i ons : [ AppComponent ] ,imports: [ BrowserModule , HttpClientModule ] ,prov iders : [ getArchetypesFromADL ] ,bootstrap: [ AppComponent ]

})

export c l a s s AppModule { }

##################### app . component . ts ######################

@Component({

s e l e c t o r : ’app−root ’ ,templateUrl: ’ ./ app . component . html ’ ,s t y l e U r l s : [ ’ ./ app . component . css ’ ] ,prov iders : [ getArchetypesFromADL ]

})

5.4.1 NPM

The npm is a Command Line Interface (CLI) package manager helper that interacts with a remoteregistry and downloads automatically or when required the external libraries and plugins for the projectthat is being developed. Although that are other versions like ”yarn”, the npm was the one chosen forthe script due to be easy to use and because it has access to a huge number of packages. For example,it can download all the necessary libraries that are necessary from Angular, like ”@angular/core” for theCore module or the HTTP client module like ”@angular/common/http” for the HTTP requests.

5.4.2 TypeScript

Typescript is a scripting language that works as a superset of JavaScript and was created by Microsoft.It has more static types, asynchronous functions and tools than JavaScript, and it can make type-checkingand auto-completion of the code while is being typed. The aim to create this new language was to makethe writing code more maintainable in large JavaScript projects.

5.5 GitHub OpenEHR CKM Mirror

OpenEHR foundation hosted at GitHub a mirror from the CKM clinical models at https://www.

openehr.org/ckm/, which automatically updates when changes are made on the CKM trunk. Since it isconnected the GitHub, it is possible to use the REST API resources from this service.

Material and Methods 82

Development and Implementa on

85 Development and Implementation

6. Development and Implementation

The subsections on this chapter explain how to create an account on ADL Designer, the web-toolused for parsing the openEHR resources, and how to connect a repository with it. Are also explainedthe steps taken for the development of the script made for archetypes compliance and comparison froma local repository with the GitHub mirror of openEHR CKM.

6.1 Programming Technologies

After analyzing all the materials that were provided, it was decided that the best platform for thescript would be by using an web browser, due to its practicality for an ordinary user. It was used theAngular 2 framework, together with the REST API calls that could be made to ADL Designer webtool/application, which works as a middleware for fetching resources from the local repositories, and toGitHub openEHR CKM repository, along with all the materials mentioned on Materials and Methodschapter. For this, was created a web-page that can run this script in the background, after using thecredentials from ADL Designer for login and authentication.

6.1.1 Script process and methodology

Before running the script, it is necessary to create an account on ADL Designer and connect the localrepository to it. If the repository of openEHR resources is not connected to this tool, the script it willnot work, since it is dependent from it.

6.1.1.1 Creating an account

The official web-page for ADL Designer is https://ehrscape.marand.si/designerv2. It has adefault account that can be logged in for testing purposes. To have a personal account is necessaryto request it at https://www.ehrscape.com/register.html. After getting an account, it is necessaryto connect the desired repository to ADL Designer. It offers connection to various cloud repositorieslike OneDrive, Google Drive, Dropbox, GitHub, Bitbucket, Box and other CVS systems like GIT orconnection to a local folder in a local machine. Depending on the chosen repository, other fields needs tobe filled up as seen in figure 6.1

Development and Implementation 86

Figure 6.1: Configuring repository connection on ADL Designer

With this, the openEHR based repository is created and connected to ADL Designer and readyto be also connected to the compliance comparison script. The repository name will be identified as”repositoryID” parameter inside of the script code.

6.1.1.2 Script Algorithm

The algorithm of the script works as follows:

1. Connect and authenticate to ADL Designer (user:password);2. Connect to repository inside of ADL Designer (repositoryID);3. GET method call to ADL Designer to get the list of archetypes and templates from the local

repository;4. Parse the object obtained from the previous call by archetypeID, UID, rmType, MD5-CAM-1.0.1,

build_uid, revision;5. GET method call for raw file URL from GitHub, that allows the archetype comparison;6. Differentiate the URL paths for each archetype RM type;7. Make comparison between versions on both repositories and return the new ones that can be found

on GitHub;8. Present results for archetype comparison (compliant or not compliant) and in case of-non internal

archetype, return the GitHub URL for the new version of archetype in ADL RAW format.

The figure 6.2 shows the previous steps in a Business Process Management and Notation (BPMN):

87 Development and Implementation

Figure 6.2: Script Process

Development and Implementation 88

6.2 Development

The script developed was based on the information taken from the objects retrieved by the REST APIGET calls of archetypes and templates from ADL Designer to the local repository, and from the structurestudy of openEHR CKM on GitHub, available on Chapter 3 - OpenEHR CKM. The information isanalyzed by the script and it returns the URLs from the updated archetype versions available at openEHRCKM mirror account. At this stage, the script only analyze and presents the archetypes from theopenEHR CKM instance of the openEHR Foundation (Publisher Namespace/Custodian Organization:org.openEHR) and only present at the ”local” folder (see image 3.7).

The classes created to received the information from the calls are presented at table 6.1, together withan example of the data received by each parameter.

Table 6.1: Classes ”Archetypes” and ”Templates” used to get information from ADL Designer calls

export c l a s s Archetypes {

dataResponse : s t r ing ; // f u l l response from ADL DesignerarchetypeId : s t r ing ; // e . g . openEHR−EHR−SECTION. adhoc . v1path : s t r ing ; // e . g . openEHR−EHR−SECTION. adhoc . v1 . adlrmType : s t r ing ; // e . g . SECTIONuid : s t r ing ; // e . g . a82233b9−7f2d−4dd5−8db4−37f6963cfd8cd e t a i l s : [ ”MD5−CAM−1.0.1” ] ; build_uid ; r ev i s i on : s t r ing ;dependsOn ;specia l izedArch : s t r ing ;urlGithubReturn ;sumArchError ;sumArchOK : number ;temp_val ;

}

export c l a s s Templates {

dataResponse : s t r ing ; // f u l l response from ADL DesignertemplateId : s t r ing ; // e . g . Vital Signs Measurement Requestuid : s t r ing ; // e . g . aa69c166−ebbd−48d2−bbfe−9fba97ddfbeadependsOn ;archetypes ;temp_val ;

}

Owing to the repository chosen for testing and proof of concept be connected to a local databasehosted at GitLab, the ”archetypeID”, ”path” and ”rmType” parameters allowed to construct and retrievethe URL link for each archetype for future comparison. Since it is a private repository, it will requirecredentials for authentication.

For the searching component on the openEHR CKM mirror repository, the ”rmType” parameterallowed to decide on which URL the archetype should be searched. In case on archetypes with the”rmType” paramater equal to ”ACTION”, ”EVALUATION”, ”OBSERVATION”, ”INSTRUCTION”and ”ADMIN_ENTRY”, the URL from GitHub should have appended the folder ”Entry”. In the other”rmType” cases, this was not necessary. The management of both cases can be seen in table 6.2.

89 Development and Implementation

Table 6.2: GET method calls, transformations and search

// ( . . . )

th i s . http . get ( githubBaseUrl + th i s . archetypeLists [ i ] . rmType . toLowerCase () + ’/ ’ +th i s . archetypeLists [ i ] . archetypeId + ’ . adl ’ , options )

. subscr ibe (

response1 => {archetypeLists [ i ] . temp_val = response . text () . startsWith ( ’ archetype ’ ) ? imgOk +statusUpd : imgNotOk + statusOut ;

} ,

response2 => {i f ( th i s . archetypeLists [ i ] . rmType . toLowerCase () === ’ action ’ | | ’ observation ’ | |’ admin_entry ’ | | ’ evaluation ’ | | ’ in s t ruct ion ’ ) {

th i s . http . get ( githubBaseUrl + ’ entry/ ’ +th i s . archetypeLists [ i ] . rmType . toLowerCase () + ’/ ’ +th i s . archetypeLists [ i ] . archetypeId + ’ . adl ’ )

. subscr ibe (response => {

archetypeLists [ i ] . temp_val = response . text () . startsWith ( ’ archetype ’ ) ? imgOk +statusUpd : imgNotOk + statusOut ;

} ,

// ( . . . )

switch ( th i s . archetypeLists [ i ] . rmType . toLowerCase () ) {case ” action ” :case ” observation ” :case ”admin_entry” :case ” evaluation ” :case ” ins t ruct ion ” :

ur l = githubBaseUrl + ’ entry/ ’ +th i s . archetypeLists [ i ] . rmType . toLowerCase () + ’/ ’ +th i s . archetypeLists [ i ] . archetypeId + ’ . adl ’ ;break ;

de fault :ur l = githubBaseUrl +th i s . archetypeLists [ i ] . rmType . toLowerCase () + ’/ ’ +th i s . archetypeLists [ i ] . archetypeId + ’ . adl ’ ;break ;

}

i f ( ur l . indexOf ( ” . v0” ) > 0) {var urlGithub = ur l . replace ( ”v0” , ”v1” ) ;console . log ( urlGithub ) ;return th i s . http . get ( urlGithub )

. subscr ibe (data => archetypeLists [ i ] . urlGithubReturn = urlGithub ,error => { archetypeLists [ i ] . urlGithubReturn = ( error . status === 200) ?urlGithub : ” Interna l ␣Archetype” }

) ;}

i f ( ur l . indexOf ( ” . v1” ) > 0) {var urlGithub = ur l . replace ( ”v1” , ”v0” ) ;return th i s . http . get ( urlGithub )

. subscr ibe (data => archetypeLists [ i ] . urlGithubReturn = urlGithub ,error => {

var urlGithub = ur l . replace ( ”v1” , ”v2” ) ;return th i s . http . get ( urlGithub )

. subscr ibe (data => { archetypeLists [ i ] . urlGithubReturn = urlGithub } ,error => { archetypeLists [ i ] . urlGithubReturn =( error . status === 200) ? urlGithub : ” Interna l ␣Archetype” }

// ( . . . )) ;

} ,) ;

}

Development and Implementation 90

With this, when the search by archetype_id is made to the openEHR CKM GitHub repository, thescript will always return the URL of the latest version available, even in cases where the major version hasbeen wrongly increased or decrease by some person responsible on the governance of the local repository.

6.3 Results

The results can be seen live at https://mim-script-openehr.stackblitz.io/.

The login section is situated on the top of the page, where the script will run. A small introductionabout the motivation of creating this script was made, along with the information of how to use it. Inthe next figures is possible to see how the page was designed together with the results retrieved from thescript, after analyzing the local repository mentioned on the Material and Methods chapter.

Figure 6.3: Script Main Page

The script web-page was divided in 3 main sections:

1. Get Archetypes list from local repository;2. Comparison from local repository and compliance with the openEHR CKM mirror at Github;3. Get Templates list from local repository;

All these sections are dependent on the successful login made previously, otherwise the web page willpresent a never-ending loading logo under each section, until the login credentials are correctly inserted.

The first section contains a table with a list of archetypes from the local repository, with the respectiveUID, MD5-CAM hash, build_uid and revision parameters, and the URL to the local repository for aquick user access. Also, each parameter presents a small explanation of its meaning.

91 Development and Implementation

Figure 6.4: Module Get Archetypes list from local repository

The second section presents the list of archetypes from the local repository (archetype_id and UID)with the comparison result, that in case of outdated archetype, it returns the URL to the newest versionon the GitHub openEHR CKM, along with the link to the version in the local repository.

Figure 6.5: Module Comparison from local repository and compliance with the openEHR CKM mirrorat Github

On the top of each section, a resume from the analyzed process was made. Since the results obtainedfrom the script were made by the archetype major version only (v.X), it was also made a comparisonanalysis with this information from the local repository provided for testing and the openEHR CKMmirror at GitHub. The result and comparison can be seen in tables 6.3 and 6.4, respectively.

Development and Implementation 92

Table 6.3: Summary of archetype comparison analysis from the provided CKM repository with GitHubmirror of openEHR international CKM and the openEHR CKM by major version difference (June 2018)(n=41)

Total (n=41)Archetype Status n (%)

Outdated 6 (14,64)Internal 16 (39,02)Not found 3 (7,32)Compliant 16 (39,02)

When comparing the manual study made from the local repository to the openEHR CKM on GitHubto the developed script, the results are:

Table 6.4: Comparison of the local repository analysis results retrieved by the manual analysis and thedeveloped script.

Manual Analysis Developed Script

Total archetypes 41 41Compliant archetypes 16 14Not found archetypes 3 N.A.Outdated archetypes 6 6Internal archetypes 16 21Outdated or Internal archetypes N.A. 27 (6 outdated, 21 internal, which are pre-

sented together in the script)

The major differences from both analysis are presented in the number of compliant archetypes andinternal archetypes. In the first case, it is due to the mirror errors from the openEHR CKM to the GitHubaccount during the committing process, where the archetypes openEHR-EHR-CLUSTER.healthcare_provider_parentand openEHR-EHR-CLUSTER.address_isa have not been mirrored, and these causes a mislead to thescript by recognizing them as internal archetypes. Other case that turns into misleading information,but in this case in the number of internal archetypes, are the archetypes whose archetype_id have beenrenamed and cannot be found anymore on the openEHR CKM. These cases are:

• openEHR-EHR-OBSERVATION.indirect_oximetry to openEHR-EHR-OBSERVATION.pulse_oximetry;• openEHR-EHR-CLUSTER.timing_repetition to openEHR-EHR-CLUSTER.timing_nondaily.

In the next image, the second section is presented in detail, with some elements from the archetypescomparison list. Although the ”red” alert for a outdated or internal archetype is appearing together, itcan be understood that the archetype that is presented with and URL from GitHub in the next column,is a case of an outdated archetype. The next archetype on the list, is a case of an archetype that existson the openEHR CKM, but it is not mirrored to the GitHub repository, which results on a ”internalarchetype” interpretation by the script.

93 Development and Implementation

Figure 6.6: Detail from comparison module, with distinction from internal, outdated and compliantarchetype

The third section, was a internal request where the internship was made for improvement and futureuse case, which retrieve the list of templates and the set of archetypes included on those templates.

Figure 6.7: Module Get Templates list from local repository

6.3.1 Performance

There was the opportunity to have the script been used and tested in three different projects byrequest. Two of them had an average of 50 archetypes and 10 templates and the other, an average of670 archetypes and 190 templates. Since the script is dependent of ADL Designer REST API calls, forfetching the content from different repositories, they need to be connected previously to ADL Designer.Currently ADL Designer supports ADL versions 1.4 and 2 of archetypes and .OET format from templates,so if the resources are not well structured or have been edited manually on a text editor, without check-ing the consistence of data (which can compromise the structuring of these resources), or are saved on a

Development and Implementation 94

different format, ADL Designer will not read them and automatically exclude this cases. The first tworepositories had really ”fresh” archetypes and templates, comparing with the third repository, that hasresources dated from 2013 and with a lot of not recognized formats (.adls, .xml, .opt) by ADL designer,which provokes the exclusion of this cases when presenting the list of resources on the script. Also if anOET template is having in his sets of archetypes, an archetype that does not exists on the repository, itwill also retrieve an error and not take this template on consideration.

The time taken for the script analysis in the third case was bigger, which took around 2,5 minutesto present all the page with the analysis and newer versions of archetypes available from GitHub, due tothe higher number of resources, than in the first two cases, that only took 8 seconds to be completed.The speed of analysis can be quicker depending on the internet connection and the machine that is beingused to run the script. This was tested on a machine with Intel i5 2nd generation processor with 6 GBof RAM with WI-FI access and a HDD drive, using Google Chrome version 68.0.3440.106 (64 bits).

Conclusions and Recommenda ons

97 Conclusions and Recommendations

7. Conclusions and Recommendations

The proposal of this thesis was to create documentation and a script to implement a suitable way ofhaving the different openEHR local repositories updated and compliant with the openEHR CKM (Clin-ical Knowledge Manager).

The usage of online repositories is in constant growth and it can become troublesome to manageall information inside of them. Regarding a clinical knowledge repository based on openEHR artefacts,this content is based on archetypes and templates, which internally have very well defined versioningparameters.

Although these versioning parameters can be very useful to distinguish internal changes and variantsof artefacts, when a project is being created and the requirements for the clinical information model aredefined, archetypes are simply downloaded from the openEHR CKM and saved in the local repositoryof the on-going project. When new versions for the same archetypes are uploaded to the openEHRCKM, they usually are not updated on the local repository. Normally, a local archetype will be updatedonly when a bug, error or new requirement is found during the usage of the software that contains thatarchetype, and a check for new version is made manually on the openEHR CKM. Following this, it iscommon to have a local repository that does not follow the updates made on the openEHR CKM, dueto variety of reasons:

1. The archetypes in the local repository did not present some issue yet and, and due to this, the mainthought would be to keep it in the way it is, which is a totally wrong behavior.

2. The verification of different archetypes versions in the openEHR CKM can be really time consuming,which leads an avoidance of verification for new resources.

This is a kind of thinking and mentality that needs to be changed inside of projects that use thisapproach. The usage of openEHR resources tells how the data will be save in an EHR system. Thearchetypes are the CORE basis of how an EHR system based on openEHR standard will take andinterpret the data. If this CORE is not well defined, the value of the health data received will be lost.An early and constant verification of new updates can be essential to a timely and effective developmentof the systems that are making use of these resources.

An ”alpha” version of a script that searches the content of an local repository connected to ADLDesigner and compares it with the openEHR CKM was made, to help the local repository owner toverify the compliance between both repositories and allows to a faster update of contents. One of itsstrengths is that it is accessible to everyone: the code is open and it has a live demo that can be accessedat https://mim-script-openehr.stackblitz.io. Still relatively to the script, the lack of time was a

Conclusions and Recommendations 98

major limitation, which not allows the full verification of versioning parameters and the comparison sideby side for each version of archetype ADL file on both repositories. Nevertheless, there is the chance tohave a continuous improvement of it in the future.

Besides that, documentation with methodologies have also been made for managing versioning of newand actual archetypes. This dissertation was divided in two parts, one for research and the other for thescript implementation.

7.1 Research Summary

The research on this dissertation was divided in four main topics:

1. Review of the openEHR specifications for Reference Model (RM) and Archetype Model (AM),related with archetype identification and versioning;

2. Understanding how the openEHR CKM works, history, features, functionalities and how the veri-fication of new versions of artifacts is made on this platform.

3. Study state of art methodologies used for managing software and document lifecycles;4. Creation of documentation about how to deal with archetype versioning on a local repository and

a script to compare the artifacts content in both repositories and verify new updates for eacharchetype from openEHR CKM;

The junction of all the information gathered from these studies allowed to create a methodology andscript with rules for version comparison. The aim of openEHR was creating a set of archetypes in a singleinternational repository (openEHR CKM) that could be used in an EHR system after being agreed bythe international online community. Is also possible to add regional or local archetypes that would stillcompatible with the previous ones inserted in the international CKM and making the information beingshareable with everybody. However, the current use of archetypes are not working in this way, due toeach project that makes use of archetypes have their own repository and, although many resources can becompliant with the openEHR CKM, other are not since few changes have been made to the archetype toreply to local specifications and requirements, and even sometimes these are not made in a proper way.

The openEHR group defined rules and methodologies for the archetype development process, com-monly called Archetype Development Life Cycle (ADLC) (Maria Madsen, 2010), based on the SoftwareDevelopment Life Cycle (SDLC). An adaptation from this set of rules can be seen in the chapter 4 (LifeCycles of Archetypes and Templates), which can be very helpful for creation and management of theseresources, along with a proposal for governance of local repositories in order to make them compliantwith the main CKM.

7.1.1 Main Findings

After study how the CKM and the archetype versioning works, a comparison between the localrepository and the openEHR CKM mirror hosted on Github was analyzed. Many problems were foundduring this stage on the GitHub openEHR CKM repository, such as:

• Archetypes that exists on openEHR CKM, but are not mirrored to the GitHub repository, e.g.:openEHR-EHR-CLUSTER.address_isa and openEHR-EHR-CLUSTER.healthcare_provider_parent.

99 Conclusions and Recommendations

• Archetypes that have been renamed and lost connection to the previous resource, although they stillhave the same content and versioning parameters, e.g.: openEHR-EHR-CLUSTER.timing_nondailyand the previous openEHR-EHR-CLUSTER.timing_repetition, or the case of the openEHR-EHR-OBSERVATION.indirect_oximetry, with the previous name openEHR-EHR-OBSERVATION.pulse_oximetry.

• Archetypes that are specialized from other archetypes (parents) and the those archetypes have beenupdated to newer versions or deleted from the repository, which make the connection between themlost.

7.1.2 Dealing with versioning of openEHR resources

During the analysis of the provided repository, there was the oportunity to have a insight at otherrepositories with openEHR artifacts of different projects, managed by different people with various back-grounds. Many issues were found related with how to deal with versioning, specializations and how togive proper names to these resources.

Some of these issues exists due to the lack of study and comprehension of how the openEHR standardworks, which needs to be very well studied first, since the wrong usage of this, can lead to a very poorway of structuring, storing and retrieving health data.

7.1.2.1 Recommendations

OpenEHR standard structures how the health data should be stored and retrieved. Nowadays thehealth data is in constant growth along with the usage of the new wearables that can be connected todevices (e.g. smartphone) and send the health data to an EHR server. If this server is implemented usingthe openEHR standard, it will require to have the core data precisely defined and updated. So whendeveloping a new system, these next steps should be taken into account:

• Study the openEHR specification and understand its reference model. It can take time, but a goodresearch and study can solve a lot of problems. Otherwise, ask an openEHR expert to give insight.Sometimes the experience and a good background in this area can improve and fasten the process.One of the biggest mistakes made by various companies is recommending or putting on charge ofopenEHR resources people that do not have a clue of how this standard works, or heathcare ingeneral. Any good tool in wrong hands can be abused even with good intentions.

• Search if the content that will be used within the project, has already some created resources inthe openEHR CKM. Use specific keywords to search your subject, choose the archetype and readthe associated header along with the use and misuse of this resource. A lot of new archetypes arecreated inside of local repositories due to a poor search on openEHR CKM. If the openEHR CKMhas your topic, but does not include everything you want, suggest a new review to include yourcontent, or specialize the one you want. About specializations, there are also rules for the archetypeHRID comformation, like the case of openEHR-EHR-OBSERVATION.fetal_heart-monitoring.v1,which is a specialization of openEHR-EHR-OBSERVATION.fetal_heart.v1. When a specializationhappens, the concept_id ”fetal_heart” gets an hyphen ”-” added to this parameter, being the final

Conclusions and Recommendations 100

result ”fetal_heart-monitoring” that allows to easily understand that is a case of specialization.Nevertheless, send your new archetype for review on the openEHR CKM. A lot of content is beingcreated and reviewed and new clinical content to enrich this platform is always welcome.

• If you create a new archetype to fit local requirements, do not name it with the same name as theother archetypes on openEHR CKM and use a correct lifecycle for the process of archetype creation.OpenEHR has very well defined parameters of how to deal with this topic. Check the chapter 3(OpenEHR CKM) and 4 (Lifecycles of Archetypes and Templates) from this dissertation.

7.1.2.2 Suggestions for the archetype governance in the openEHR CKM

• It would be helpful to get within the archetype, under the description section, the list of majorchanges made to that archetype. For example, in a similar way to the custodian organizationhistory mentioned on table 4.1, if the archetype_id was changed, the old names could appear as ahistory list, like the case of openEHR-EHR-EVALUATION.alcohol_use_summary that was havingthe archetype_id changed for a few days:

Table 7.1: Proposal example of archetype_id history changes

descr ipt ionoriginal_purposed_name = <

[ ”name” ] = <”openEHR−EHR−EVALUATION. alcohol_use_summary”>[ ”date” ] = <”2018−08−30”>

new_purposed_name = <[ ”name” ] = <”openEHR−EHR−EVALUATION. alcohol_drinking_summary”>[ ”date” ] = <”2018−08−31”>

new_purposed_name = <[ ”name” ] = <”openEHR−EHR−EVALUATION. alcohol_consumption_summary”>[ ”date” ] = <”2018−08−31”>

>

This can be extremely useful for a responsible person who is making the governance of openEHRartefacts of a local repository. Even if it is a case of a draft archetype, there is a huge percentageof them being downloaded from the openEHR CKM to the local repositories and being used indeveloped and deployed projects. When a archetype_id is changed, this results in an easily losttracking of all the updates done to that archetype. Even when searching on the openEHR CKMby the old archetype_id, the search returns ”no results”.

• A double check to the updates made from the openEHR CKM to the GitHub mirror repositorycan also help for a better maintenance and governance. Mistakes can happen during the procedureof commiting new changes, where some archetypes could not be sent successfully, but a compliantrepository hosted on GitHub with the openEHR CKM allows the possibility to develop a lot ofapplications for the openEHR environment, using the available REST APIs.

• Include more people on the team reviews. During the making of this dissertation, the openEHRstandard along with the openEHR CKM had a exponential grow in new users, projects and onresearch. With this is necessary to verify more quickly the archetypes that have been submitted.Almost half of the openEHR CKM resources are in draft mode, and although they should not be

101 Conclusions and Recommendations

used (Ljosland, 2015), the projects that are deployed or under development end up using theseunpublished resources.

7.2 Script Summary

When developing projects using online repositories, the amount of data will always increase andsometimes the entropy can become troublesome to manage all information inside of it. Regarding a clinicalknowledge repository based on openEHR artefacts, this content is based on archetypes and templateswhich internally have very well defined versioning parameters. Although these versioning parameters canbe very useful to distinguish internal changes and variants of artefacts, when a project is being createdand the requirements for the clinical information model are defined, archetypes are simply downloadedfrom the openEHR CKM and saved in the local repository of the on-going project. When new versionsfor the same archetypes are uploaded to the openEHR CKM, they usually are not updated on the localrepository. Normally a local archetype will be updated only when a bug, error or new requirement isfound during the usage of the software that contains that archetype and a check for new version is mademanually on the openEHR CKM.

One of the biggest problems of manually checking versions on openEHR CKM is that it can be reallytime consuming, for example the archetype comparison mentioned on table 5.1, took several hours tocomplete. Usually checking new versions of archetypes is avoided due to the time that it consumes tobe finished. Herewith this documentation and the script created, it is expected to give a quick andreliable archetype verification between the local repositories and the openEHR CKM, in order to makeit compliant and updated with the main source, and facilitate the managing work of the local clinicalknowledge repository owner.

Moreover about the script, this is the first version and was developed as a proof of concept (POC) usingthe archetype HRID to help managing the search in the REST API calls: (rm_publisher-model_name-rm_class.concept_id.v.major). This version only checks if the archetype on the local repository has amajor version (e.g. v0 to v1) in the openEHR CKM and it returns the uniform resource locator (URL)links from the different repositories allowing to make a side by side comparison of both versions.

7.2.1 Limitations

The main findings reported on subsection 9.1.1, can cause issues when running the script, since somearchetypes that exist on openEHR CKM and are not mirrored to the openEHR CKM account, will notbe found and the script will understand them as an ”Internal Archetype”. The openEHR CKM mirrorrepository at GitHub needs to be fully analyzed and updated wherefore to be compliant to with theopenEHR CKM. Currently the verification is just made by the major version of archetypes in both repos-itories, the internal versioning parameters are not being used yet.

Another finding that can hinder the functionality of this script, is the need of change a bigger numberof archetype_ids in the openEHR CKM, in the month before the delivery of this dissertation. Althoughit was expectable that some archetype could have the name changed during the during the v0 phase ofreviewing process, it was surprising that in the period of July to August 2018, six archetypes suffer those

Conclusions and Recommendations 102

changes on their names/ids, and some of them with three changes in two days. On these cases, the scriptwill refer the previous archetype versions as an internal archetypes.

Future Work

105 Future Work

8. Future Work

In the future, it is expected to have a continuous improvement of this script, by adding new featuresto it, that can simplify even more the process of updating archetypes.

Sometimes the changes on the archetypes can be only a new language added to the archetype and, insome of these cases, it is not necessary to update the archetype locally. One of the future improvementsis the implementation of the archetype parsing functionality, in order to get fully internal versioningdifferences from the parameters MD5-CAM, build_uid and revision in the archetypes of either reposito-ries. These resources can also suffer smaller changes during a period of time, and these changes can benoticed by a difference on the previous parameters. Other functionality to be implemented is having afully functional differences (”diff”) comparison, that will allow to the side by side the different versionsof archetypes from both repositories and check all the changes made on both.

Also, another improvement will be implementing a new module to the script to verify the commitsmade to the GitHub CKM, and in case of the message that follow that script is ”The archetype id waschanged.”, make a list of what was the previous archetype_id and the new one, returning the links todownload the new version.

Future Work 106

References

109 References

9. References

Bacelar, G. and Correia, R. (2015). Manual de introdução à norma openehr. OpenEHR Academy.

Beale, T. and Heard, S. (2007a). Archetype definitions and principles. Rev. 0.5. TheOpenEHR Foundation. https://www.openehr.org/releases/1.0.2/architecture/am/archetype_

principles.pdf (accessed December 7, 2017).

Beale, T. and Heard, S. (2007b). An ontology-based model of clinical information. Stud Health TechnolInform. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.204.2580 (accessed Oc-tober 25, 2017).

Bowman, S. E. (2005). Coordination of snomed-ct and icd-10: getting the most outof electronic health record systems. AHIMA, American Health Information ManagementAssociation. http://www.ijri.org/article.asp?issn=0971-3026;year=2012;volume=22;issue=

1;spage=4;epage=13;aulast=Varma;t=6 (accessed December 4, 2017).

CDC (2018). Classification of diseases, functioning, and disability - international classification of diseases,tenth revision, clinical modification (icd-10-cm). https://www.cdc.gov/nchs/icd/icd10cm.htm (ac-cessed November 9, 2017).

Chacon, S. and Straub, B. (2014). Pro git. Apress. https://git-scm.com/book/en/v2 (accessed March1, 2017).

Conde, A. M. and Berry, D. (2010). Towards best practice in the archetype development process. ProyectoFin de Carrera, Trinity College Dublin. https://www.scss.tcd.ie/publications/theses/diss/

2010/TCD-SCSS-DISSERTATION-2010-016.pdf (accessed February 26, 2018).

Cresswell, K. M., Bates, D. W., and Sheikh, A. (2013). Ten key considerations for the successful imple-mentation and adoption of large-scale health information technology. Journal of the American MedicalInformatics Association, 20(e1):e9–e13.

Detmer, D. E., Steen, E. B., Dick, R. S., et al. (1997). The computer-based patient record: an essentialtechnology for health care. https://www.ncbi.nlm.nih.gov/books/NBK233055/ (accessed June 12,2017).

Dick, R. S., Steen, E. B., Detmer, D. E., et al. (1997). Computer-based patient record technologies.https://www.ncbi.nlm.nih.gov/books/NBK233053/ (accessed August 30, 2017).

DICOM (2018). Dicom ps3.1 2018c - introduction and overview. http://dicom.nema.org/medical/

dicom/current/output/pdf/part01.pdf (accessed November 24, 2017).

References 110

Evans, R. (2016). Electronic health records: then, now, and in the future. Yearbook of medicalinformatics, 25(S 01):S48–S61. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC61236/ (accessedAugust 25, 2017).

Eysenbach, G. (2001). What is e-health? J Med Internet Res 2001;3(2):e20, 3. http://www.jmir.org/

2001/2/e20/ (accessed July 10, 2017).

FHIR, H. (2017a). Fhir overview - architects introduction. http://hl7.org/fhir/2016sep/

overview-arch.html (accessed October 21, 2017).

FHIR, H. (2017b). Introducing hl7 fhir. https://www.hl7.org/fhir/summary.html (accessed October8, 2017).

Google (2018). Google angular 2+ architecture overview. Angular. https://angular.io/guide/

architecture (accessed May 25, 2018).

Grandia, L. (2017). Healthcare information systems: A look at the past, present, and future. https:

//www.healthcatalyst.com/insights/healthcare-information-systems-past-present-future

(accessed June 12, 2017).

Grieve, G. (2016). Fhir and openehr. HL7 FHIR developer days 2016 Amsterdam. https://www.

fhirdevdays.com/amsterdam/previous-editions/devdays-2016/ (accessed April 17, 2018).

Grieve, G., Julian, A., Koncar, M., Robertson, S., Pratt, D., Ruggeri, R., and Spronk, R. (2012). Hl7 ver-sion 3 standard: Abstract transport specification. https://www.hl7.org/documentcenter/public_

temp_79969D68-1C23-BA17-0CC88BC2FA652C92/wg/inm/abstract_transports.html (accessed Au-gust 26, 2018).

Hammond, W. E., Jaffe, C., Cimino, J. J., and Huff, S. M. (2014). Standards in biomedical informatics.In Biomedical informatics, pages 211–253. Springer.

HIMSS (2013). Definition of interoperability. http://www.himss.org/sites/himssorg/

files/FileDownloads/HIMSS%20Interoperability%20Definition%20FINAL.pdf (accessed August8, 2017).

Hovenga, E. J. and Grain, H. (2013). Health data and data governance. Health Information Governancein a Digital Environment, 193:384. https://www.ncbi.nlm.nih.gov/pubmed/24018511 (accessed Au-gust 20, 2017).

Huff, S. M., Rocha, R. A., Bray, B. E., Warner, H. R., and Haug, P. J. (1995). An event model of medicalinformation representation. Journal of the American Medical Informatics Association, 2(2):116–134.https://www.ncbi.nlm.nih.gov/pubmed/7743315 (accessed February 11, 2018).

IHE (2018). Integrating the healthcare enterprise - the ihe process. https://www.ihe.net/resources/

technical_frameworks/ (accessed October 20, 2017).

IHTSDO (2017). What is snomed ct? - snomed ct starter guide. https://www.snomed.org/snomed-ct/

what-is-snomed-ct (accessed November 31, 2017).

111 References

Ingram, D. (2016). Origins of openehr. OpenEHR Foundation. https://www.openehr.org/about/

origins (accessed June 14, 2017).

ISO (1994). Iec 7498-1: 1994 information technology–open systems interconnection–basic reference model:The basic model. ISO standard ISO/IEC, pages 7498–1. https://www.iso.org/obp/ui/#iso:std:

iso-iec:7498:-1:ed-1:v2:en (accessed October 20, 2017).

ISO (2008). Information technology - framework and taxonomy of international standardized pro-files. ISO standard ISO/IEC. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.

204.2580 (accessed August 26, 2017).

Kalra, D., Beale, T., and Heard, S. (2005). The openehr foundation. Studies in health technology andinformatics, 115:153–173. https://europepmc.org/abstract/med/16160223 (accessed September 13,2017).

Kniberg, H. (2017). Spotify engineering culture (part 1 and part 2) [video blog post]. https://labs.

spotify.com/2014/03/27/spotify-engineering-culture-part-1/ (accessed August 5, 2018).

Kniberg, H. and Ivarsson, A. (2012). Scaling agile at spotify with tribes, squads, chapters and guilds.https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (accessed August 5,2018).

Leslie, H. (2008). Archetype authoring, review and publication. OpenEHR Foundation.https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949174/Archetype+

authoring+review+and+publication (accessed March 15, 2018).

Leslie, H. (2017). Authoring, review and publication overview. OpenEHR Foundation.https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949146/Authoring+Review+

and+Publication+Overview (accessed March 15, 2018).

Leslie, H. and Heard, S. (2006). Archetypes 101. HIC 2006 and HINZ 2006: Proceedings,Health Informatics Society of Australia. https://www.researchgate.net/publication/228702894_

Archetypes_101 (accessed March 20, 2018).

Ljosland, S. B. (2015). National governance of archetypes in norway. Studies in health technology andinformatics, 216:1091–1091. https://www.ncbi.nlm.nih.gov/pubmed/26262390 (accessed March 19,2018).

Loeliger, J. and McCullough, M. (2012). Version Control with Git: Powerful tools and techniques forcollaborative software development. ” O’Reilly Media, Inc.”.

Marand (2017). Think!ehr platform™ documentation and specification. Marand d.o.o. http://www.

marand.com/thinkehr/ (accessed October 3, 2017).

Marcos, M. and Martínez-Salvador, B. (2010). Towards the interoperability of computerized guide-lines and electronic health records: an experiment with openehr archetypes and a chronic heartfailure guideline. In International Workshop on Knowledge Representation for Health Care,pages 101–113. Springer. https://www.researchgate.net/publication/220836902_Towards_

References 112

the_Interoperability_of_Computerised_Guidelines_and_Electronic_Health_Records_An_

Experiment_with_openEHR_Archetypes_and_a_Chronic_Heart_Failure_Guideline (accessedAugust 30, 2018).

Maria Madsen, H. L. e. a. (2010). Sustainable clinical knowledge management: An archetype developmentlife cycle. IOS Press, Volume 151: Health Informatics:115 – 132. http://ebooks.iospress.nl/

publication/12910 (accessed March 19, 2018).

McDonald, C. J. (1997). The barriers to electronic medical record systems and how to overcome them.Journal of the American Medical Informatics Association, 4(3):213–221. https://www.ncbi.nlm.nih.

gov/pmc/articles/PMC61236/ (accessed August 25, 2017).

Min, L., Tian, Q., Lu, X., and Duan, H. (2018). Modeling ehr with the openehr approach: an ex-ploratory study in china. BMC Medical Informatics and Decision Making, page 18:75. https:

//bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-018-0650-6 (accessedSeptember 1, 2018).

Moner, D., Maldonado, J. A., and Robles, M. (2018). Archetype modeling methodology. Journalof biomedical informatics, 79:71–81. https://www.sciencedirect.com/science/article/pii/

S1532046418300224 (accessed September 1, 2018).

OpenEHR (2016). Adl designer github page repository and specification. https://github.com/openEHR/

adl-designer (accessed April 16, 2018).

OpenEHR (2017a). What is openehr? https://www.openehr.org/what_is_openehr (accessed August10, 2017).

OpenEHR (2017b). Who is using openehr? - deployed solutions. https://www.openehr.org/who_is_

using_openehr/healthcare_providers_and_authorities (accessed June 20, 2017).

OpenEHR (2018a). Archetype identification specification - distributed governance, manage-ment. https://www.openehr.org/releases/AM/latest/docs/Identification/Identification.

html#_management (accessed August 10, 2017).

OpenEHR (2018b). Archetype identification specification - lifecycle model - lifecycle-based version-ing. https://www.openehr.org/releases/AM/latest/docs/Identification/Identification.

html#_management (accessed August 10, 2017).

OpenEHR (2018c). National clinical knowledge managers repositories (ckms). https://www.openehr.

org/programs/clinicalmodels/nationalckms (accessed August 3, 2017).

OpenEHR (2018d). Openehr aom2 (archetype object model 2) versioning. OpenEHR Foundation.https://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html#

_versioning (accessed February 18, 2018).

OpenEHR (2018e). Openehr archetype identification specification program. OpenEHR Foundation.https://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html

(accessed February 24, 2018).

113 References

OpenEHR (2018f). Openehr archetype object model (aom2) specification program. OpenEHRFoundation. https://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_human_

readable_identifier_hrid (accessed June 3, 2018).

OpenEHR (2018g). Openehr architecture overview - archetypes and templates overview. OpenEHRFoundation. https://www.openehr.org/releases/BASE/latest/docs/architecture_overview/

architecture_overview.html (accessed May 24, 2017).

Peham, T. (2017). Gitlab vs github: Key differences and similarities. https://usersnap.com/blog/

gitlab-github/ (accessed May 11, 2018).

Piho, G., Tepandi, J., Thompson, D., Woerner, A., and Parman, M. (2015). Business archetypesand archetype patterns from the hl7 rim and openehr rm perspectives: Towards interop-erability and evolution of healthcare models and software systems. Procedia ComputerScience, 63:553–560. https://www.researchgate.net/publication/283170849_Business_

Archetypes_and_Archetype_Patterns_from_the_HL7_RIM_and_openEHR_RM_Perspectives_

Towards_Interoperability_and_Evolution_of_Healthcare_Models_and_Software_Systems

(accessed March 28, 2018).

Preston-Werner, T. (2018). Semantic versioning 2.0.0 - meaningful method for incrementing versionnumbers. https://semver.org/ (accessed February 18, 2017).

Regenstrief, I. (2018a). Loinc term basics. https://loinc.org/get-started/loinc-term-basics/

(accessed August 15, 2017).

Regenstrief, I. (2018b). Scope of loinc. https://loinc.org/get-started/scope-of-loinc/ (accessedNovember 15, 2017).

Selinger, P. (2006). Collisions in the md5 cryptographic hash function - md5 collision demo. https:

//www.mathstat.dal.ca/~selinger/md5collision/ (accessed July 3, 2018).

Sinha, P. K., Sunder, G., Bendale, P., Mantri, M., and Dande, A. (2012). Electronic health record:standards, coding systems, frameworks, and infrastructures. John Wiley & Sons.

Sundvall, E., Nyström, M., Karlsson, D., Eneling, M., Chen, R., and Örman, H. (2013). Applyingrepresentational state transfer (rest) architecture to archetype-based electronic health record sys-tems. BMC medical informatics and decision making, 13(1):57. https://bmcmedinformdecismak.

biomedcentral.com/articles/10.1186/1472-6947-13-57 (accessed February 16, 2018).

Tolk, A. and Muguira, J. A. (2003). The levels of conceptual interoperability model.https://www.researchgate.net/publication/240319008_The_Levels_of_Conceptual_

Interoperability_Model (accessed February 24, 2018).

Varma, D. (2012). Managing DICOM images: Tips and tricks for the radiologist. Indian Journalof Radiology and Imaging, 22(1):4–13. http://www.ijri.org/article.asp?issn=0971-3026;year=

2012;volume=22;issue=1;spage=4;epage=13;aulast=Varma;t=6 (accessed November 27, 2017).

Wade, T. D. (2014). Traits and types of health data repositories. Health information science and systems,2(1):4. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4340801/ (accessed May 22, 2018).

References 114

WHO (2017). International classification of diseases documentation and specification. http://apps.

who.int/classifications/icd10/browse/2016/en#/V (accessed December 2, 2017).

Wilcox, A. B., Narus, S. P., and Vawdrey, D. K. (2014). Software engineering for health care andbiomedicine. In Biomedical Informatics, pages 185–209. Springer. https://www.scss.tcd.ie/

publications/theses/diss/2010/TCD-SCSS-DISSERTATION-2010-016.pdf (accessed February 26,2018).

Wilson, G. (2017). Introduction to git for data science. https://www.datacamp.com/courses/

introduction-to-git-for-data-science (accessed February 24, 2018).

Annexes

117 Annexes

10. Annexes

10.1 Comparison of compliant archetypes between the providedrepository from GitLab and the GitHub mirror of openEHRCKM, with the respective status (”outdated”, ”compli-ant”, ”internal” and ”not found”)

Archetype name from provided repository

Provided repository Major version and revision

openEHR-CKM Github mirror major version and revision

Status Comments

openEHR-EHR-OBSERVATION.blood_pressure v1 (1.1.0) v1 (1.1.2) outdated ------------

openEHR-EHR-OBSERVATION.body_temperature v1 (no revision) v2 (2.0.2) outdated ------------

openEHR-EHR-OBSERVATION.body_weight v1 (no revision) v2 (2.0.1) outdated ------------

openEHR-EHR-OBSERVATION.height v1 (no revision) v2 (2.0.1) outdated ------------

openEHR-EHR-OBSERVATION.indirect_oximetry v1 (no revision) New archetype: openEHR-EHR-OBSERVATION.pulse_oximetry.v1 (1.0.1)

not found Substituted by pulse oximetry in openEHR CKM

openEHR-EHR-OBSERVATION.pulse v1 (1.0.0) v1 (1.0.0) outdated minor changes from one archetype to another, major version and revision still the same, but MD5 Hash is different

openEHR-EHR-OBSERVATION.pathology_test-blood_glucose

v1 (no revision) it is a specialization from openEHR-EHR-OBSERVATION.pathology_test.v1, which cannot be found on openEHR CKM

not found Specialization of an archetype that no longer more exists on openEHR CKM

openEHR-EHR-OBSERVATION.six_minute_walk_test.v0

v0 - internal archetype, made by request, not submitted to openEHR CKM

do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-OBSERVATION.ecg v0 (0.0.1-alpha) v0 (0.0.1-alpha) compliant minor changes from one archetype to another, major version, revision and MD5 Hash still the same

openEHR-EHR-OBSERVATION.ecg_report v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-INSTRUCTION.request-telemonitoring

v0 (0.0.1-alpha) it is a specialization from openEHR-EHR-INSTRUCTION.request.v0, which cannot be found on openEHR CKM, since it has been updated to openEHR-EHR-INSTRUCTION.request.v1

Internal Specialization of an archetype that no longer more exists on openEHR CKM

openEHR-EHR-INSTRUCTION.request v0 (0.0.1-alpha) openEHR-EHR-INSTRUCTION.request-procedure.v0 specialize openEHR-EHR-INSTRUCTION.request.v0, wihich does not exist anymore on openEHR CKM

Internal Specialization of an archetype that no longer more exists on openEHR CKM

openEHR-EHR-COMPOSITION.request v1 (1.1.0) v1 (1.1.0) compliant minor changes from one archetype to another, major version, revision and MD5 Hash still the same

openEHR-EHR-COMPOSITION.report v1 (1.1.0) v1 (1.1.0) outdated minor changes from one archetype to another, major version and revision still the same, but MD5 Hash is different - the changes are more related to new languages supported

openEHR-EHR-COMPOSITION.encounter v1 (1.0.0) v1 (1.0.1) outdated ------------

openEHR-EHR-COMPOSITION.appointment v0 - internal archetype, made by request, not submitted to openEHR CKM

do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.timing_repetition v0 (0.0.1-alpha) New archetype: openEHR-EHR-CLUSTER.timing_nondaily.v1

not found ------------

openEHR-EHR-CLUSTER.timing_daily v0 (0.0.1-alpha) v1 (1.0.0) outdated ------------

openEHR-EHR-CLUSTER.multimedia v1 (no revision) v0 (0.0.1-alpha) outdated In the archetype of the provided repository, the version was incorrectly inserted. Probably some human-error dealing with versioning. The v0 on openEHR CKM is correct and has even more information

openEHR-EHR-CLUSTER.healthcare_provider_parent

v1 (no revision) v1 (no revision) - check comments

compliant CRITICAL - Although it appears on openEHR CKM, it seems that wasn't submmited to the CKM github mirror

openEHR-EHR-CLUSTER.encounter_context v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.device_hand_over_checklist

v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.device_details v1 (no revision) v1 (no revision) compliant missing archetype uid on the github mirror openEHR

openEHR-EHR-CLUSTER.device v1 (no revision) v1 (1.0.1) outdated ------------

openEHR-EHR-CLUSTER.clinical_evidence v1 (1.0.0) v1 (1.1.0) outdated ------------

openEHR-EHR-CLUSTER.complications v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.intermacs_profiles v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.intermacs_profiles-slo

v0 (no revision) it is a specialization from openEHR-EHR-CLUSTER.intermacs_profiles.v0, which cannot be found on openEHR CKM, since it is another internal archetype from ACHF project.

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.malignacy_details v0 (no revision) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.nyha_heart_failure-slo

v1 (1.0.0-alpha) it is a specialization from openEHR-EHR-CLUSTER.nyha_heart_failure.v1 from the same repository (internal archetype), but it is based on github openEHR CKM openEHR-EHR-OBSERVATION.nyha_heart_failure.v0

Internal This archetype only exists in the provided repository

openEHR-EHR-CLUSTER.nyha_heart_failure v1 (1.0.0-alpha) do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided

repository ACHF project in marand

openEHR-EHR-CLUSTER.address_isa v1 (no revision) v1 (no revision) compliant CRITICAL - Although it appears on openEHR CKM, it seems that wasn't submmited to the CKM github mirror. Also missing archetype uid.

openEHR-EHR-ADMIN_ENTRY.patient_process_status

v0 (no revision) - internal archetype, made by request, not submitted to openEHR CKM

do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-ADMIN_ENTRY.remote_monitoring_preferences

v0 - internal archetype, made by request, not submitted to openEHR CKM

do not exist on github mirror openEHR CKM

Internal This archetype only exists in the provided repository

openEHR-EHR-ACTION.service v0 (0.0.1-alpha) v0 (0.0.1-alpha) compliant The numbers of versions are the same, but UID and MD5 are not. The content of both versions are also similar. Probably there were changes submitted to openEHR CKM from different files (derivated frim remote archetypes).

openEHR-EHR-ACTION.informed_consent v1 (no revision) v0 (0.0.1-alpha) outdated On ACHF archetype, the version was incorrectly inserted. Probably some human-error dealing with versioning or edited to take out some not necessary parts. This should not be done this way. The v0 on openEHR CKM is correct and has even more information

openEHR-EHR-EVALUATION.absence v1 (1.0.0) v1 (1.0.0) compliant ------------

openEHR-EHR-EVALUATION.exclusion-problem_diagnosis

v0 (0.0.1-alpha) it is a specialization from openEHR-EHR-EVALUATION.exclusion.v1 from the same repository (internal archetype), which does not exist in the ACHF repository. But it is based on github openEHR CKM openEHR-EHR-EVALUATION.exclusion_global.v1 (1.1.1)

Internal This archetype only exists in the provided repository

openEHR-EHR-EVALUATION.problem_diagnosis v1 (1.0.2) v1 (1.0.5) outdated ------------

openEHR-EHR-OBSERVATION.container v0 (0.0.1-alpha) v0 (0.0.1-alpha) compliant ------------

openEHR-EHR-SECTION.adhoc v1 (1.0.0) v1 (1.0.1) compliant minor changes - portuguese language added

Date of comparison: 16 June 2018