-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
868 lines (836 loc) · 86.4 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head>
<meta charset="utf-8">
<meta name="generator" content="quarto-1.4.553">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<meta name="author" content="Daniel Kapitan">
<meta name="author" content="Femke Heddema">
<meta name="author" content="Andre Dekker">
<meta name="author" content="Melle Sieswerda">
<meta name="author" content="Bart-Jan Verhoeff">
<meta name="author" content="Matt Berg">
<meta name="keywords" content="OMOP, openEHR, FHIR, secondary use, data platform, digital platform">
<title>Data interoperability in context: the importance of open source implementations when choosing open standards</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
div.columns{display: flex; gap: min(4vw, 1.5em);}
div.column{flex: auto; overflow-x: auto;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
ul.task-list li input[type="checkbox"] {
width: 0.8em;
margin: 0 0.8em 0.2em -1em; /* quarto-specific, see https://github.com/quarto-dev/quarto-cli/issues/4556 */
vertical-align: middle;
}
/* CSS for citations */
div.csl-bib-body { }
div.csl-entry {
clear: both;
}
.hanging-indent div.csl-entry {
margin-left:2em;
text-indent:-2em;
}
div.csl-left-margin {
min-width:2em;
float:left;
}
div.csl-right-inline {
margin-left:2em;
padding-left:1em;
}
div.csl-indent {
margin-left: 2em;
}</style>
<script src="index_files/libs/clipboard/clipboard.min.js"></script>
<script src="index_files/libs/quarto-html/quarto.js"></script>
<script src="index_files/libs/quarto-html/popper.min.js"></script>
<script src="index_files/libs/quarto-html/tippy.umd.min.js"></script>
<script src="index_files/libs/quarto-html/anchor.min.js"></script>
<link href="index_files/libs/quarto-html/tippy.css" rel="stylesheet">
<link href="index_files/libs/quarto-html/quarto-syntax-highlighting.css" rel="stylesheet" id="quarto-text-highlighting-styles">
<script src="index_files/libs/bootstrap/bootstrap.min.js"></script>
<link href="index_files/libs/bootstrap/bootstrap-icons.css" rel="stylesheet">
<link href="index_files/libs/bootstrap/bootstrap.min.css" rel="stylesheet" id="quarto-bootstrap" data-mode="light">
</head>
<body>
<div id="quarto-content" class="page-columns page-rows-contents page-layout-article">
<div id="quarto-margin-sidebar" class="sidebar margin-sidebar">
<nav id="TOC" role="doc-toc" class="toc-active">
<h2 id="toc-title">Table of contents</h2>
<ul class="collapse">
<li><a href="#open-standards-are-a-necessary-but-not-sufficient-condition-for-interoperability" id="toc-open-standards-are-a-necessary-but-not-sufficient-condition-for-interoperability" class="nav-link active" data-scroll-target="#open-standards-are-a-necessary-but-not-sufficient-condition-for-interoperability">Open standards are a necessary but not sufficient condition for interoperability</a></li>
<li><a href="#digital-platforms-require-extensibility-availibility-of-complementary-components-and-availibility-of-executable-pieces-of-software" id="toc-digital-platforms-require-extensibility-availibility-of-complementary-components-and-availibility-of-executable-pieces-of-software" class="nav-link" data-scroll-target="#digital-platforms-require-extensibility-availibility-of-complementary-components-and-availibility-of-executable-pieces-of-software">Digital platforms require extensibility, availibility of complementary components and availibility of executable pieces of software</a></li>
<li><a href="#standardization-of-health-data-for-federated-learning" id="toc-standardization-of-health-data-for-federated-learning" class="nav-link" data-scroll-target="#standardization-of-health-data-for-federated-learning">Standardization of health data for federated learning</a></li>
<li><a href="#health-data-standards-in-lmics" id="toc-health-data-standards-in-lmics" class="nav-link" data-scroll-target="#health-data-standards-in-lmics">Health data standards in LMICs</a></li>
<li><a href="#conclusion" id="toc-conclusion" class="nav-link" data-scroll-target="#conclusion">Conclusion</a></li>
<li><a href="#bibliography" id="toc-bibliography" class="nav-link" data-scroll-target="#bibliography">References</a></li>
</ul>
<div class="quarto-alternate-formats"><h2>Other Formats</h2><ul><li><a href="index.pdf"><i class="bi bi-file-pdf"></i>PDF</a></li><li><a href="index.docx"><i class="bi bi-file-word"></i>MS Word</a></li></ul></div></nav>
</div>
<main class="content" id="quarto-document-content">
<header id="title-block-header" class="quarto-title-block default">
<div class="quarto-title">
<h1 class="title">Data interoperability in context: the importance of open source implementations when choosing open standards</h1>
</div>
<div class="quarto-title-meta-author">
<div class="quarto-title-meta-heading">Authors</div>
<div class="quarto-title-meta-heading">Affiliations</div>
<div class="quarto-title-meta-contents">
<p class="author">Daniel Kapitan <a href="mailto:[email protected]" class="quarto-title-author-email"><i class="bi bi-envelope"></i></a> <a href="https://orcid.org/0000-0001-8979-9194" class="quarto-title-author-orcid"> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAA2ZpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo1N0NEMjA4MDI1MjA2ODExOTk0QzkzNTEzRjZEQTg1NyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDozM0NDOEJGNEZGNTcxMUUxODdBOEVCODg2RjdCQ0QwOSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDozM0NDOEJGM0ZGNTcxMUUxODdBOEVCODg2RjdCQ0QwOSIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOkZDN0YxMTc0MDcyMDY4MTE5NUZFRDc5MUM2MUUwNEREIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOjU3Q0QyMDgwMjUyMDY4MTE5OTRDOTM1MTNGNkRBODU3Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+84NovQAAAR1JREFUeNpiZEADy85ZJgCpeCB2QJM6AMQLo4yOL0AWZETSqACk1gOxAQN+cAGIA4EGPQBxmJA0nwdpjjQ8xqArmczw5tMHXAaALDgP1QMxAGqzAAPxQACqh4ER6uf5MBlkm0X4EGayMfMw/Pr7Bd2gRBZogMFBrv01hisv5jLsv9nLAPIOMnjy8RDDyYctyAbFM2EJbRQw+aAWw/LzVgx7b+cwCHKqMhjJFCBLOzAR6+lXX84xnHjYyqAo5IUizkRCwIENQQckGSDGY4TVgAPEaraQr2a4/24bSuoExcJCfAEJihXkWDj3ZAKy9EJGaEo8T0QSxkjSwORsCAuDQCD+QILmD1A9kECEZgxDaEZhICIzGcIyEyOl2RkgwAAhkmC+eAm0TAAAAABJRU5ErkJggg=="></a></p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Dutch Hospital Data
</p>
<p class="affiliation">
PharmAccess Foundation
</p>
<p class="affiliation">
Eindhoven University of Technology
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Femke Heddema </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
PharmAccess Foundation
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Andre Dekker <a href="https://orcid.org/0000-0002-0422-7996" class="quarto-title-author-orcid"> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAA2ZpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo1N0NEMjA4MDI1MjA2ODExOTk0QzkzNTEzRjZEQTg1NyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDozM0NDOEJGNEZGNTcxMUUxODdBOEVCODg2RjdCQ0QwOSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDozM0NDOEJGM0ZGNTcxMUUxODdBOEVCODg2RjdCQ0QwOSIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOkZDN0YxMTc0MDcyMDY4MTE5NUZFRDc5MUM2MUUwNEREIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOjU3Q0QyMDgwMjUyMDY4MTE5OTRDOTM1MTNGNkRBODU3Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+84NovQAAAR1JREFUeNpiZEADy85ZJgCpeCB2QJM6AMQLo4yOL0AWZETSqACk1gOxAQN+cAGIA4EGPQBxmJA0nwdpjjQ8xqArmczw5tMHXAaALDgP1QMxAGqzAAPxQACqh4ER6uf5MBlkm0X4EGayMfMw/Pr7Bd2gRBZogMFBrv01hisv5jLsv9nLAPIOMnjy8RDDyYctyAbFM2EJbRQw+aAWw/LzVgx7b+cwCHKqMhjJFCBLOzAR6+lXX84xnHjYyqAo5IUizkRCwIENQQckGSDGY4TVgAPEaraQr2a4/24bSuoExcJCfAEJihXkWDj3ZAKy9EJGaEo8T0QSxkjSwORsCAuDQCD+QILmD1A9kECEZgxDaEZhICIzGcIyEyOl2RkgwAAhkmC+eAm0TAAAAABJRU5ErkJggg=="></a></p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Department of Radiation Oncology (Maastro), GROW - Research Institute for Oncology and Reproduction, Maastricht University Medical Center+
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Melle Sieswerda </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Integral Cancer Registry Netherlands
</p>
<p class="affiliation">
Maastricht University
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Bart-Jan Verhoeff </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Expertisecentrum Zorgalgoritmen
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Matt Berg </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Ona
</p>
</div>
</div>
<div class="quarto-title-meta">
</div>
<div>
<div class="abstract">
<div class="block-title">Abstract</div>
<p>In response to the proposal of Tsafnat et al. to converge towards three open health data standards, this viewpoint provides a critical reflection on the proposed alignment of using openEHR, FHIR and OMOP as the default standards for clinical care and administration, data exchange and longitudinal analysis, respectively. We argue that open standards are a necessary but not sufficient condition to achieve health data interoperability. The ecosystem of open source implementations needs to be considered when choosing an appropriate standard for a given context. We discuss two specific contexts, namely standardization of i) health data for federated learning, and ii) health data sharing in low- and middle income countries (LMICs). Specific design principles, practical considerations and implementation choices for these two contexts are described, based on ongoing work in both areas. In the case of federated learning, we observe convergence towards OMOP and FHIR, where the two standards can effectively be used side-by-side given the availibility of mediators between the two. In the case of health information exchanges in LMICs, we see a strong convergence towards FHIR as the primary standard, with as yet limited adoption of OMOP and openEHR. We propose practical guidelines for context-specific adaptation of open standards.</p>
</div>
</div>
<div>
<div class="keywords">
<div class="block-title">Keywords</div>
<p>OMOP, openEHR, FHIR, secondary use, data platform, digital platform</p>
</div>
</div>
</header>
<section id="open-standards-are-a-necessary-but-not-sufficient-condition-for-interoperability" class="level2">
<h2 class="anchored" data-anchor-id="open-standards-are-a-necessary-but-not-sufficient-condition-for-interoperability">Open standards are a necessary but not sufficient condition for interoperability</h2>
<p>“A paradox of health care interoperability is the existence of a large number of standards with significant overlap among them,” say Tsafnat et al., followed by a call to actions towards the health informatics community to put effort into establishing convergence and preventing collision <span class="citation" data-cites="tsafnat2024converge">[<a href="#ref-tsafnat2024converge" role="doc-biblioref">1</a>]</span>. To do so, they propose to converge on three open standards, namely i) openEHR for clinical care and administration; ii) Fast Health Interoperability Resources (FHIR) for data exchange and iii) Observational Medical Outcomes Partnership Common Data Model (OMOP) for longitudinal analysis. They argue that open data standards, backed by engaged communities, hold an advantage over proprietary ones and therefore should be chosen as the steppingstones towards achieving true interoperability.</p>
<p>While we support their high-level rationale and intention, we feel their proposed trichotomy does not do justice to details that are crucial in real-world implementations. This viewpoint provides a critical reflection on their proposed framework in three parts. First, we reflect on salient differences between the three open standards from the perspective of the notion of openness of digital platforms <span class="citation" data-cites="dereuver2018digital">[<a href="#ref-dereuver2018digital" role="doc-biblioref">2</a>]</span> and the paradox of open <span class="citation" data-cites="keller2021paradox">[<a href="#ref-keller2021paradox" role="doc-biblioref">3</a>]</span>. Subsequently, we outline the importance of the open source ecosystem by reflecting on our considerations in designing and implementing health data platforms in two specific contexts, namely i) platforms for federated learning on shared health data in high income countries; and ii) health data platforms for low and middle income countries (LMICs). We conclude with practical guidelines for context-specific adaptation of open standards.</p>
</section>
<section id="digital-platforms-require-extensibility-availibility-of-complementary-components-and-availibility-of-executable-pieces-of-software" class="level2">
<h2 class="anchored" data-anchor-id="digital-platforms-require-extensibility-availibility-of-complementary-components-and-availibility-of-executable-pieces-of-software">Digital platforms require extensibility, availibility of complementary components and availibility of executable pieces of software</h2>
<p>In their editorial, Tsafnat et al. argue that i) the paradox of interoperability of having overlapping standards can be addressed by converging on just three standards; ii) practical and socio-technical considerations are as important as, if not more important than, technical superiority and therefore balancing of customizibility and rigidity is of the essence; and iii) open standards, backed by engaged communities, hold an advantage over proprietary ones. While we concur with these points, we argue that these are necessary, but not sufficient conditions for convergence of health data standards. Existing research on digital platforms underlines the importance of the platform openness, not only in terms of open standards, but also in terms of availibility of executable pieces of software, extensibility of the code base and availibility of complements to the core technical platform (in this case the health data standard is the core technical platform) <span class="citation" data-cites="dereuver2018digital">[<a href="#ref-dereuver2018digital" role="doc-biblioref">2</a>]</span>. Only when the majority of these aspects of digital platforms are met can we resonably expect that the digital platform will indeed flourish and longlived.</p>
<p>A similar line of reasoning has been put forward by Keller and Tarkowski in what they call the paradox of open, namely that open ecosystems can only flourish if two types of conditions are met <span class="citation" data-cites="keller2021paradox">[<a href="#ref-keller2021paradox" role="doc-biblioref">3</a>]</span>. The first condition states that many people need to contribute to the creation of a common resource. “This is the story of Wikipedia, OpenStreetMap, Blender.org, and the countless free software projects that provide much of the internet’s infrastructure.” <span class="citation" data-cites="keller2021paradox">[<a href="#ref-keller2021paradox" role="doc-biblioref">3</a>]</span> Indeed, Tsafnat et al. have explicitly taken into account that “an engaged and vibrant community is a major advantage for the longevity of the data standards it uses,” which has informed their proposal to converge towards OMOP, FHIR en openEHR. However, the emphasis on open source implementations is somewhat overlooked. This point is only mentioned in passing when Tsafnat et al. reference work done by Reynolds and Wyatt who already argued in 2011 “… for the superiority of open source licensing to promote safer, more effective health care information systems. We claim that open source licensing in health care information systems is essential to rational procurement strategy” <span class="citation" data-cites="reynolds2011open">[<a href="#ref-reynolds2011open" role="doc-biblioref">4</a>]</span>. Hence, we extend the line of reasoning of Tsafnat et al. by emphasizing that the availability of executable pieces of software, extensibility of the code base and availibility of complementary components is an important criterion which needs to be explicitly taken into account when choosing which standard to adopt.</p>
<p>The second condition put forward by Keller and Tarkoswki is that open ecosystems have proven fruitful when “opening up” is the result of external incentives or requirements, rather than voluntary actions. Examples of such external incentives are “… publicly-funded knowledge production like Open Access academic publications, cultural heritage collections in the Public Domain, Open Educational Resources (OER), and Open Government data.” <span class="citation" data-cites="keller2021paradox">[<a href="#ref-keller2021paradox" role="doc-biblioref">3</a>]</span> Another canonical example is the birth of the GSM standard, which was mandated by European legislation <span class="citation" data-cites="wikipedia-gsm">[<a href="#ref-wikipedia-gsm" role="doc-biblioref">5</a>]</span>. Reflecting on this condition in the context of open health data ecosystems, we observe a salient difference between FHIR vis-a-vis openEHR and OMOP, namely that the former is the only one that has been mandated (or at least strongly recommended) in some jurisdictions. In the US, the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare and Medicaid Services (CMS) have introduced a steady stream of new regulations, criteria, and deadlines in Health IT that has resulted in significant adoption of FHIR <span class="citation" data-cites="firely2023fhir">[<a href="#ref-firely2023fhir" role="doc-biblioref">6</a>]</span>. In India, the open Health Claims Exchange protocol specification - which is based on FHIR - has been mandated by the Indian government as the standard for e-claims handling <span class="citation" data-cites="india2020national 2023hcx">[<a href="#ref-india2020national" role="doc-biblioref">7</a>,<a href="#ref-2023hcx" role="doc-biblioref">8</a>]</span>. The African Union recommends all new implementations and digital health system improvements use FHIR as the primary mechanism for data exchange <span class="citation" data-cites="tilahun2023african">[<a href="#ref-tilahun2023african" role="doc-biblioref">9</a>]</span>, but doesn’t say anything about the use of, for example, openEHR for administrative point-of-service systems. The upcoming legislation on the European Health Data Space (EHDS) mandates interoperability between electronic health record systems but has not specified which standard is to be used, although FHIR and openEHR have both been mentioned in the legislative discussion.</p>
<p>These external incentives have resulted in a large boost in both commercial and open source development activities in the FHIR ecosystem. Illustrative of this is the speed with which the Bulk FHIR API has been defined and implemented in almost all major implementations <span class="citation" data-cites="mandl2020push jones2021landscape">[<a href="#ref-mandl2020push" role="doc-biblioref">10</a>,<a href="#ref-jones2021landscape" role="doc-biblioref">11</a>]</span>, and the the SQL-on-FHIR specification to make large-scale analysis of FHIR data accessible to a larger audience and portable between systems <span class="citation" data-cites="sql-on-fhir-v2">[<a href="#ref-sql-on-fhir-v2" role="doc-biblioref">12</a>]</span>. It has also led to more people voluntarily contributing to FHIR-related open source projects, which has resulted in a wide offering of FHIR components across major technology stacks (Java, Python, .NET), thereby strengthening the first condition. By comparison, OMOP and openEHR have not yet profited from external incentives to spur the adoption and thereby growing the ecosystem beyond a certain critical mass. To illustrate this, a search on GitHub on “FHIR” yields 8.2 thousand results, “OMOP or OHDSI” one thousand results, and “openEHR” returns 400 results. A quick-scan of the available open source components listed on the website of the three governing bodies HL7 <span class="citation" data-cites="fhir-implementations">[<a href="#ref-fhir-implementations" role="doc-biblioref">13</a>]</span>, OHDSI <span class="citation" data-cites="ohdsi-implementations">[<a href="#ref-ohdsi-implementations" role="doc-biblioref">14</a>]</span> and openEHR <span class="citation" data-cites="openehr-implementations">[<a href="#ref-openehr-implementations" role="doc-biblioref">15</a>]</span>, indicates that the ecosystem of FHIR and OMOP have a significantly larger offering of extensible and complementary open source components than openEHR, although for the latter notable mature open source implementation are also emerging such as EHRbase <span class="citation" data-cites="ehrbase">[<a href="#ref-ehrbase" role="doc-biblioref">16</a>]</span>.</p>
<p>Hence, we stress that beyond evaluating the instrinic structure of an open standard and the community that supports the standard, we need to take into account the wider ecosystem of open source implementations and availibility of complementary components. From this wider perspective of the whole ecosystem surrounding the three standards, FHIR stands out as having the most diverse and rich ecosystem because it has been mandated in certain jurisdictions. This is relevant when comparing these standards in real-world implementations. We now turn to two specific use contexts where these considerations are at play.</p>
</section>
<section id="standardization-of-health-data-for-federated-learning" class="level2">
<h2 class="anchored" data-anchor-id="standardization-of-health-data-for-federated-learning">Standardization of health data for federated learning</h2>
<p>The current fragmentation in health data is one of the major barriers towards leveraging the potential medical data for machine learning (ML). Without access to sufficient data, ML will be limited in its application to health improvement efforts and, ultimately, from making the transition from research to clinical practice. High quality health data, obtained from a research setting or a real-world clinical practice setting, is hard to obtain, because health data is highly sensitive and its usage is tightly regulated.</p>
<p>Federated learning (FL) is a learning paradigm that aims to address these issues of data governance and privacy by training algorithms collaboratively without moving (copying) the data itself <span class="citation" data-cites="rieke2020future teo2024federated">[<a href="#ref-rieke2020future" role="doc-biblioref">17</a>,<a href="#ref-teo2024federated" role="doc-biblioref">18</a>]</span>. Based on ongoing work with the PLUGIN healthcare consortium (<a href="https://plugin.healthcare">https://plugin.healthcare</a>, in Dutch) we have detailed an architecture for FL for secondary use of health data for hospitals in the Netherlands. Starting point for this implementation are the National Health Data Infrastructure agreements for research, policy and innovation for the Dutch healthcare sector, which have been adopted at the beginning of 2024 <span class="citation" data-cites="healthri2024agreements">[<a href="#ref-healthri2024agreements" role="doc-biblioref">19</a>]</span>. <a href="#fig-healthri-architecture" class="quarto-xref">Figure 1</a> shows a high level reference architecture of the infrastructure to be, comprising three areas (multiple use, applications and generic features) and a total of 26 functional components (for details please refer to <span class="citation" data-cites="healthri2024agreements">[<a href="#ref-healthri2024agreements" role="doc-biblioref">19</a>]</span>). One of the prerequisites of this architecture is that organizations that participate in a federation of ‘data stations’ use the same common data model to make the data Findable, Accessible, Interoperable and Resusable (FAIR). These FAIR data stations comprise components 7, 8 and 9 in <a href="#fig-healthri-architecture" class="quarto-xref">Figure 1</a>, i.e. the data, metadata and APIs, respectively, through which this the data station can be accessed and used.</p>
<div id="fig-healthri-architecture" class="quarto-figure quarto-figure-center quarto-float anchored">
<figure class="quarto-float quarto-float-fig figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-fig" id="fig-healthri-architecture-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 1: Reference architecture for the Dutch health data infrastructure for research and innovation <span class="citation" data-cites="healthri2024agreements">[<a href="#ref-healthri2024agreements" role="doc-biblioref">19</a>]</span>
</figcaption>
<div aria-describedby="fig-healthri-architecture-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="health-ri-architecture.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>Following the line of reasoning of Tsafnat et al., OMOP would be the go-to standard for storing the longitudinal data in each of the data stations, where data is transformed from the original source (component 6), stored in common data model (component 7) and properly annotated with metadata (component 8). Indeed, by now there are quite a few reports of real-world implementations of federated learning networks based on the OHDSI-OMOP stack, including a global infrastructure with 22 centres for COVID19 prediction models <span class="citation" data-cites="khalid2021standardized">[<a href="#ref-khalid2021standardized" role="doc-biblioref">20</a>]</span>, FeederNet in South Korea with 57 participating hospitals <span class="citation" data-cites="lee2022feedernet">[<a href="#ref-lee2022feedernet" role="doc-biblioref">21</a>]</span>, Dutch multi-cohort dementia research with 9 centres <span class="citation" data-cites="mateus2024data">[<a href="#ref-mateus2024data" role="doc-biblioref">22</a>]</span>, the European severe heterogeneous asthma research collaboration <span class="citation" data-cites="kroes2022blueprint">[<a href="#ref-kroes2022blueprint" role="doc-biblioref">23</a>]</span> and the recently initiated Belgian Federated Health Innovation Network (FHIN) <span class="citation" data-cites="deltomme2024federated">[<a href="#ref-deltomme2024federated" role="doc-biblioref">24</a>]</span>.</p>
<p>For the PLUGIN project, however, we choose to adopt FHIR as the common data model because of its practicality and extensibility to be used in a Python-based data science stack, provenance of RESTful APIs out-of-the-box to facilitate easy integration with the container-based vantage6 FL framework, and the support of many healthcare terminologies and flexibility through the profiling mechanims <span class="citation" data-cites="choudhury2020personal smits2022improved">[<a href="#ref-choudhury2020personal" role="doc-biblioref">25</a>,<a href="#ref-smits2022improved" role="doc-biblioref">26</a>]</span>. Increasingly, other projects have reported the use of FHIR for persistent, longitudinal storage for FL. The CODA platform, which aims to implement a FL infrastructure in Canada similar to the PLUGIN project, compared OMOP and FHIR and chose the latter as it has been found to support more granular mappings required for analytics <span class="citation" data-cites="mullie2023coda">[<a href="#ref-mullie2023coda" role="doc-biblioref">27</a>]</span>. The fair4health project used FHIR as part of a FAIRification workflow to simplify the process of data extraction and preparation for clinical study analyses <span class="citation" data-cites="sinaci2024privacypreserving">[<a href="#ref-sinaci2024privacypreserving" role="doc-biblioref">28</a>]</span>.</p>
<p>Given that OMOP can be conceptually viewed as a strict subset of FHIR, hybrid solutions using OMOP and FHIR combined have also been reported, such as the German KETOS platform <span class="citation" data-cites="gruendner2019ketos">[<a href="#ref-gruendner2019ketos" role="doc-biblioref">29</a>]</span>, and the preliminary findings from the European GenoMed4All project which aims to connect clinical and -omics data <span class="citation" data-cites="cremonesi2023need">[<a href="#ref-cremonesi2023need" role="doc-biblioref">30</a>]</span>. A collaboration of 10 university hospitals in Germany have shown that standardized ETL-processing from FHIR into OMOP can achieve 99% conformance <span class="citation" data-cites="peng2023etlprocess">[<a href="#ref-peng2023etlprocess" role="doc-biblioref">31</a>]</span>, which confirms the feasiblity of the solution pattern where FHIR acts as an intermediate sharing standard through which data from (legacy) systems are extracted and made available for reuse in a common data model. One could argue that the distiction between FHIR amd OMOP becomes less relevant if data can be effectively stored in either standard. We are hopeful that initiatives like OMOP-on-FHIR indeed will foster convergence rather than collision between these two standards <span class="citation" data-cites="omoponfhir">[<a href="#ref-omoponfhir" role="doc-biblioref">32</a>]</span>.</p>
<p>In the case of PLUGIN, another important consideration for choosing FHIR over OMOP is, that from a data architecture perspective, the mechanism of FHIR Profiles can be tied to principle of late binding commonly applied in data lake/warehouse architectures: allow ingest of widely different sources, and gradually add more constraints and validations as you move closer to a specific use case. If machine learning is the primary objective for secondary use, we want to be able to cast a wider net of relevant data, rather than being too restrictive when ingesting the data at the start of processing pipeline. Late binding in data warehousing is a design philosophy where data transformation and schema enforcement are deferred as late as possible in the data processing pipeline, sometimes even until query time. This approach contrasts with early binding, where data is transformed and structured as it is ingested into the data warehouse. This principle is visualized as concentric circles (<a href="#fig-late-binding" class="quarto-xref">Figure 2</a>). The advantages of this design is that it allows for greater flexibility. During the initial ingestion of the data, we only require the data to conform to the minimal syntactic standard defined by the base FHIR version (R4 in the diagram). As the data is processed, more strict checks and constraints are applied, whereby ultimately different profiles can co-exists next to one another (the two most inner circles), within a larger circle with fewer strictions. This approach does not support the extension mechanism of FHIR, so we need to be cautious if we decide to use that.</p>
<div id="fig-late-binding" class="quarto-figure quarto-figure-center quarto-float anchored">
<figure class="quarto-float quarto-float-fig figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-fig" id="fig-late-binding-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 2: Principle of late binding with FHIR profiling mechanism, illustrated with FHIR Profiles that are currently in use in the Netherlands.
</figcaption>
<div aria-describedby="fig-late-binding-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="late-binding.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>We found that this principle of late binding also allows flexible and efficient implementations of the data stations that make use of the current best practices of a lakehouse architecture of <span class="citation" data-cites="hai2023data harby2022data harby2024data">[<a href="#ref-hai2023data" role="doc-biblioref">33</a>–<a href="#ref-harby2024data" role="doc-biblioref">35</a>]</span> and the composable data stack <span class="citation" data-cites="pedreira2023composable">[<a href="#ref-pedreira2023composable" role="doc-biblioref">36</a>]</span>. Lakehouses typically have a zonal architecture that follow the Extract-Load-Transform pattern (ELT) where data is ingested from the source systems in bulk (E), delivered to storage with aligned schemas (L) and transformed into a format ready for analysis (T) <span class="citation" data-cites="hai2023data">[<a href="#ref-hai2023data" role="doc-biblioref">33</a>]</span>. The discerning characteristic of the lakehouse architecture is its foundation on low-cost and directly-accessible storage that also provides traditional database management and performance features such as ACID transactions, data versioning, auditing, indexing, caching, and query optimization <span class="citation" data-cites="armbrust2021lakehouse">[<a href="#ref-armbrust2021lakehouse" role="doc-biblioref">37</a>]</span>. Lakehouses thus combine the key benefits of data lakes and data warehouses: low-cost storage in an open format accessible by a variety of systems from the former, and powerful management and optimization features from the latter. By explicitly aligining the mechanism of FHIR Profiles with this design pattern of a data lakehouse enables us to use complementary standards and open source components, most notably Apache Arrow as the standard columnar in-memory format with RPC-based data movement <span class="citation" data-cites="apache-arrow">[<a href="#ref-apache-arrow" role="doc-biblioref">38</a>]</span>; Apache Parquet as the standard columnar on-disk format <span class="citation" data-cites="apache-parquet">[<a href="#ref-apache-parquet" role="doc-biblioref">39</a>]</span>; and Apache Iceberg as the open table format <span class="citation" data-cites="jain2023analyzing apache-iceberg">[<a href="#ref-jain2023analyzing" role="doc-biblioref">40</a>,<a href="#ref-apache-iceberg" role="doc-biblioref">41</a>]</span>.</p>
<p>The main disadvantage in using FHIR in this way pertains to the need for upgrading the whole ELT pipeline when upgrading to a new primary FHIR version, for example R5. However, we expect that the development time required to upgrade FHIR versions is significantly less than the initial migration to FHIR.</p>
<p>The above considerations also show the conceptual difference of FHIR as a health data exchange standard versus openEHR as a persistent storage of healthcare data and OMOP as a persistent storage of health research data. For health data exchange and federated learning, the recipient of the data determines to a large extent what subset of data available in the source needs to be made available – i.e. the target data model is known late and this favors late binding. In a persistent storage setting, the holder of the source data determines what data needs to be stored – and typically everything – which favors early binding.</p>
</section>
<section id="health-data-standards-in-lmics" class="level2">
<h2 class="anchored" data-anchor-id="health-data-standards-in-lmics">Health data standards in LMICs</h2>
<p>It is a widely held belief that digital technologies have an important role to play in strengthening health systems in LMICs. Yet, also here the current fragmentation of health data stands in the way of scaling up digital health programmes beyond project-centric, vertical solutions into sustainable health information exchanges <span class="citation" data-cites="karamagi2022ehealth">[<a href="#ref-karamagi2022ehealth" role="doc-biblioref">42</a>]</span>. Mehl et al. have called for convergence to open standards, similar to Tsafnat et al., but additionally stress the need for open source technologies (our main argument of this paper), open content (representations of public health, health system or clinical knowledge to guide implementations) and open architectures (reusable enterprise architecture patterns for health systems) <span class="citation" data-cites="mehl2023fullstac">[<a href="#ref-mehl2023fullstac" role="doc-biblioref">43</a>]</span>. As for the open architecture, we see a convergence towards the OpenHIE framework <span class="citation" data-cites="openhie">[<a href="#ref-openhie" role="doc-biblioref">44</a>]</span>, which has been adopted by many sub-Saharan African countries as the architectural blueprint for implementing nation-wide health information exchanges (HIE) <span class="citation" data-cites="mamuye2022health">[<a href="#ref-mamuye2022health" role="doc-biblioref">45</a>]</span>, including Nigeria <span class="citation" data-cites="dalhatu2023paper">[<a href="#ref-dalhatu2023paper" role="doc-biblioref">46</a>]</span>, Kenya <span class="citation" data-cites="thaiya2021adoption">[<a href="#ref-thaiya2021adoption" role="doc-biblioref">47</a>]</span> and Tanzania <span class="citation" data-cites="nsaghurwe2021one">[<a href="#ref-nsaghurwe2021one" role="doc-biblioref">48</a>]</span>. <a href="#fig-openhie" class="quarto-xref">Figure 3</a> shows an overview of the OpenHIE architecture.</p>
<div id="fig-openhie" class="quarto-figure quarto-figure-center quarto-float anchored">
<figure class="quarto-float quarto-float-fig figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-fig" id="fig-openhie-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 3: OpenHIE architecture showing the Point of Service systems (black), the Interoperability Layer (green) and the Component Layer (blue).
</figcaption>
<div aria-describedby="fig-openhie-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="openhie.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>While the OpenHIE specification is agnostic to which data standard should be used, in practice the digital health community in LMICs have <em>de facto</em> converged towards FHIR as the primary standard for health information exchange, in line with the proposal by Tsafnat et al. . To illustrate this point, consider the OpenHIM Platform architecture, which is currently the largest open source implementation of the OpenHIE specification <a href="#fig-openhim-platform" class="quarto-xref">Figure 4</a>. Clients (Point-of-Service systems) can initiate various workflows to submit or query patient data. The Shared Health Record (SHR) acts as the core transactional system for the health information exchange, which in this case is realized with the HAPI FHIR server, being one of the most widely used open source FHIR server implementations <span class="citation" data-cites="hapi-fhir">[<a href="#ref-hapi-fhir" role="doc-biblioref">49</a>]</span>.</p>
<div id="fig-openhim-platform" class="quarto-figure quarto-figure-center quarto-float anchored">
<figure class="quarto-float quarto-float-fig figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-fig" id="fig-openhim-platform-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 4: OpenHIM Platform Architecture, illustrating the use of FHIR-based workflows between the components as specified in OpenHIE. CR: Client Registry. IOL: Interoperability Layer. MPI: Master Patient Index. SHR: Shared Health Record. Image taken from <a href="https://jembi.gitbook.io/">https://jembi.gitbook.io/</a>.
</figcaption>
<div aria-describedby="fig-openhim-platform-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="openhim-platform.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>Looking at the Point-of-Service systems, we see that as of today openEHR does not play any role of significance as the standard for clinical administration. Within the context of LMICs, the largest open source EHR implementations are based on proprietary data models, and it is unlikely this will change any time soon <span class="citation" data-cites="syzdykova2017opensource">[<a href="#ref-syzdykova2017opensource" role="doc-biblioref">50</a>]</span>. Instead, we see that FHIR-native software development frameworks such as OpenSRP <span class="citation" data-cites="mehl2020open">[<a href="#ref-mehl2020open" role="doc-biblioref">51</a>]</span> and the Open Health Stack <span class="citation" data-cites="open-health-stack">[<a href="#ref-open-health-stack" role="doc-biblioref">52</a>]</span> are being used more and more, where Android apps are used for clinical administration by health professionals (<a href="#fig-opensrp" class="quarto-xref">Figure 5</a>). OpenSRP has been deployed in 14 countries targeting various patient populations, amongst which a reference implementation of the WHO antenatal and neonatal care guidelines for midwives in Lombok, Indonesia <span class="citation" data-cites="summitinstitutefordevelopment2023bunda kurniawan2019midwife">[<a href="#ref-summitinstitutefordevelopment2023bunda" role="doc-biblioref">53</a>,<a href="#ref-kurniawan2019midwife" role="doc-biblioref">54</a>]</span>. This solution design is particularly useful for mid-size and smaller healthcare facilities, which are often resource constrained, lacking basic IT infrastructure to deploy a full-blown electronic medical record system. Hence, by necessity, the FHIR-based SHR functions as the clinical administration system of record and as the hub for information exchange at the same time.</p>
<div id="fig-opensrp" class="quarto-figure quarto-figure-center quarto-float anchored">
<figure class="quarto-float quarto-float-fig figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-fig" id="fig-opensrp-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 5: Overview of OpenSRP2 open source framework for building clinical administration apps. HIS: health information systems. Image source: <a href="https://docs.opensrp.io/">https://docs.opensrp.io/</a>.
</figcaption>
<div aria-describedby="fig-opensrp-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="opensrp.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>Finally, regarding longitudinal data analysis we also see a convergence towards FHIR as the primary standard. As is the case of federated learning, the choice for FHIR to implement datawarehouse and analytic platforms is the preferred method due to the widespread availibility of complementary open source technologies. FHIR-specific technologies such as Bulk FHIR data access and SQL-on-FHIR mentioned earlier, allow the FHIR ecosystem to be used, complemented and integrated with generic open source datawarehousing technologies such as Clickhouse <span class="citation" data-cites="clickhouse">[<a href="#ref-clickhouse" role="doc-biblioref">55</a>]</span>] and dbt <span class="citation" data-cites="dbt">[<a href="#ref-dbt" role="doc-biblioref">56</a>]</span>.</p>
<p>All in all, we see that in the context of LMICs, the standardization of the three domains put forward by Tsafnat merge into one. The SHR, as the key component within the OpenHIE specification, serves as the back-end of the system-of-record and provides a transactional, persistent storage engine for information exchange. Downstream longitudinal data stores continue to use FHIR as the common data model for analytical purposes. One could argue that it is in fact advantageous to converge to just one standard, thereby reducing complexity and cost of the total system. Such a perspective ties in with the hourglass model of layered systems architecture which has been used in the design of the Internet and Unix and has enabled viral adoption and deployment scalibility <span class="citation" data-cites="estrin2010health beck2019hourglass">[<a href="#ref-estrin2010health" role="doc-biblioref">57</a>,<a href="#ref-beck2019hourglass" role="doc-biblioref">58</a>]</span>. The hourglass mode is “… an approach to design that seeks to support a great diversity of applications (at the top of the hourglass) and allow implementation using a great diversity of supporting services (at the bottom).” <span class="citation" data-cites="beck2019hourglass">[<a href="#ref-beck2019hourglass" role="doc-biblioref">58</a>]</span> The center of the hourglass - the waist or also called the spanning layer in the information systems parlance - is defined by a set of minimal standards which mediates all interactions between the higher and lower layers. In case of the Internet, the spanning layer is defined by the TCP/IP protocol, which is supported by a variety of supporting services (many different physical networks) and used in building various applications (email, videoconferencing etc.).</p>
<p>Within the context of LMICs, we believe that FHIR can act as the spanning layer within open health data system at large. Because FHIR is inherently designed to make optimal use of internet standards, such as the json file format and REST APIs, it is very modular and developer friendly. The many components that make up the FHIR allows the standard to be used effectively to implement subsystems, such as a facility registry or a health worker registry. In comparison, OMOP and openEHR are less modular in their design and are thereby less suitable as a standard to implement the subsystems defined, for example, in the OpenHIE specification.</p>
</section>
<section id="conclusion" class="level2">
<h2 class="anchored" data-anchor-id="conclusion">Conclusion</h2>
<p>We agree with Tsafnat et al. that there is a dire need to converge to open data standards in healthcare, and support the proposal to focus on openEHR, FHIR and OMOP in healthcare informatics going forward. However, open standards are a necessary but not sufficient condition for the convergence of health data standardization. The availability of open source implementations and complementary technologies are as important when choosing which open standard to use. Furthermore, we find that the proposed trichotomy is not always relevant. As an alternative, we find that the full-STAC approach described by Mehl et al. more comprehensive. In the case of FL, we see a convergence towards OMOP and FHIR, which can be used interchangeably. In the case of LMICs, we think that FHIR as the potential of acting as the spanning layer within the open health data system at large, thereby enabling much wider standardization and adoption. We strongly support ongoing developments to increase the availibility of open source implementations as digital public goods <span class="citation" data-cites="digitalpublicgoods">[<a href="#ref-digitalpublicgoods" role="doc-biblioref">59</a>]</span> and integration projects such as Instant OpenHIE <span class="citation" data-cites="instant-openhie-v2">[<a href="#ref-instant-openhie-v2" role="doc-biblioref">60</a>]</span>, through which we have a fighting chance to move the needle in health data standardization for LMICs.</p>
</section>
<section id="bibliography" class="level1 unnumbered">
</section>
<div id="quarto-appendix" class="default"><section class="quarto-appendix-contents" role="doc-bibliography" id="quarto-bibliography"><h2 class="anchored quarto-appendix-heading">References</h2><div id="refs" class="references csl-bib-body" role="list">
<div id="ref-tsafnat2024converge" class="csl-entry" role="listitem">
<div class="csl-left-margin">1. </div><div class="csl-right-inline">Tsafnat G, Dunscombe R, Gabriel D, Grieve G, Reich C. Converge or collide? <span>Making</span> sense of a plethora of open data standards in healthcare: An editorial. 2024. Accessed April 2, 2024. <a href="https://preprints.jmir.org/preprint/55779">https://preprints.jmir.org/preprint/55779</a></div>
</div>
<div id="ref-dereuver2018digital" class="csl-entry" role="listitem">
<div class="csl-left-margin">2. </div><div class="csl-right-inline">de Reuver M, Sørensen C, Basole RC. The <span>Digital Platform</span>: <span>A Research Agenda</span>. <em>Journal of Information Technology</em>. 2018;33(2):124-135. doi:<a href="https://doi.org/10.1057/s41265-016-0033-3">10.1057/s41265-016-0033-3</a></div>
</div>
<div id="ref-keller2021paradox" class="csl-entry" role="listitem">
<div class="csl-left-margin">3. </div><div class="csl-right-inline">Keller P, Tarkowski A. The <span>Paradox</span> of <span>Open</span>. <em>Open Future</em>. Published online March 5, 2021. Accessed March 25, 2024. <a href="https://openfuture.pubpub.org/pub/paradox-of-open/release/1">https://openfuture.pubpub.org/pub/paradox-of-open/release/1</a></div>
</div>
<div id="ref-reynolds2011open" class="csl-entry" role="listitem">
<div class="csl-left-margin">4. </div><div class="csl-right-inline">Reynolds CJ, Wyatt JC. Open <span>Source</span>, <span>Open Standards</span>, and <span>Health Care Information Systems</span>. <em>Journal of Medical Internet Research</em>. 2011;13(1):e1521. doi:<a href="https://doi.org/10.2196/jmir.1521">10.2196/jmir.1521</a></div>
</div>
<div id="ref-wikipedia-gsm" class="csl-entry" role="listitem">
<div class="csl-left-margin">5. </div><div class="csl-right-inline"><span>GSM</span>. In: <em>Wikipedia</em>.; 2024. Accessed September 20, 2024. <a href="https://en.wikipedia.org/w/index.php?title=GSM&oldid=1245675274">https://en.wikipedia.org/w/index.php?title=GSM&oldid=1245675274</a></div>
</div>
<div id="ref-firely2023fhir" class="csl-entry" role="listitem">
<div class="csl-left-margin">6. </div><div class="csl-right-inline">Firely. <em><span>FHIR</span> in <span>US</span> Healthcare Regulations</em>.; 2023. Accessed May 30, 2024. <a href="https://simplifier.net/organization/firely/news/153">https://simplifier.net/organization/firely/news/153</a></div>
</div>
<div id="ref-india2020national" class="csl-entry" role="listitem">
<div class="csl-left-margin">7. </div><div class="csl-right-inline"><em>National <span>Digital Health Mission</span></em>. India National Health Authority; 2020.</div>
</div>
<div id="ref-2023hcx" class="csl-entry" role="listitem">
<div class="csl-left-margin">8. </div><div class="csl-right-inline"><em><span>HCX Protocol</span> V0.9</em>.; 2023. Accessed September 18, 2024. <a href="http://hcxprotocol.io/">http://hcxprotocol.io/</a></div>
</div>
<div id="ref-tilahun2023african" class="csl-entry" role="listitem">
<div class="csl-left-margin">9. </div><div class="csl-right-inline">Tilahun B, Mamuye A, Yilma T, Shehata Y. <em>African <span>Union Health Information Exchange Guidelines</span> and <span>Standards</span></em>.; 2023.</div>
</div>
<div id="ref-mandl2020push" class="csl-entry" role="listitem">
<div class="csl-left-margin">10. </div><div class="csl-right-inline">Mandl KD, Gottlieb D, Mandel JC, et al. Push <span>Button Population Health</span>: <span>The SMART</span>/<span>HL7 FHIR Bulk Data Access Application Programming Interface</span>. <em>npj Digital Medicine</em>. 2020;3(1):1-9. doi:<a href="https://doi.org/10.1038/s41746-020-00358-4">10.1038/s41746-020-00358-4</a></div>
</div>
<div id="ref-jones2021landscape" class="csl-entry" role="listitem">
<div class="csl-left-margin">11. </div><div class="csl-right-inline">Jones J, Gottlieb D, Mandel JC, et al. A landscape survey of planned <span>SMART</span>/<span>HL7</span> bulk <span>FHIR</span> data access <span>API</span> implementations and tools. <em>Journal of the American Medical Informatics Association</em>. 2021;28(6):1284-1287. doi:<a href="https://doi.org/10.1093/jamia/ocab028">10.1093/jamia/ocab028</a></div>
</div>
<div id="ref-sql-on-fhir-v2" class="csl-entry" role="listitem">
<div class="csl-left-margin">12. </div><div class="csl-right-inline"><em><span>SQL</span> on <span>FHIR</span> V2.0.0-Pre</em>. Accessed September 20, 2024. <a href="https://build.fhir.org/ig/FHIR/sql-on-fhir-v2/">https://build.fhir.org/ig/FHIR/sql-on-fhir-v2/</a></div>
</div>
<div id="ref-fhir-implementations" class="csl-entry" role="listitem">
<div class="csl-left-margin">13. </div><div class="csl-right-inline"><span>FHIR Open Source Implementations</span>. September 20, 2024. Accessed September 20, 2024. <a href="https://confluence.hl7.org/display/FHIR/Open+Source+Implementations">https://confluence.hl7.org/display/FHIR/Open+Source+Implementations</a></div>
</div>
<div id="ref-ohdsi-implementations" class="csl-entry" role="listitem">
<div class="csl-left-margin">14. </div><div class="csl-right-inline">Software <span>Tools</span> – <span>OHDSI</span>. Accessed September 20, 2024. <a href="https://www.ohdsi.org/software-tools/">https://www.ohdsi.org/software-tools/</a></div>
</div>
<div id="ref-openehr-implementations" class="csl-entry" role="listitem">
<div class="csl-left-margin">15. </div><div class="csl-right-inline">Beale SH Thomas. <span class="nocase">openEHR Platform</span>. Accessed September 20, 2024. <a href="https://openehr.org/products_tools/platform/">https://openehr.org/products_tools/platform/</a></div>
</div>
<div id="ref-ehrbase" class="csl-entry" role="listitem">
<div class="csl-left-margin">16. </div><div class="csl-right-inline"><span>EHRbase</span> 2.0 website. Published online March 19, 2024. Accessed September 20, 2024. <a href="https://www.ehrbase.org/">https://www.ehrbase.org/</a></div>
</div>
<div id="ref-rieke2020future" class="csl-entry" role="listitem">
<div class="csl-left-margin">17. </div><div class="csl-right-inline">Rieke N, Hancox J, Li W, et al. The future of digital health with federated learning. <em>npj Digit Med</em>. 2020;3(1, 1):1-7. doi:<a href="https://doi.org/10.1038/s41746-020-00323-1">10.1038/s41746-020-00323-1</a></div>
</div>
<div id="ref-teo2024federated" class="csl-entry" role="listitem">
<div class="csl-left-margin">18. </div><div class="csl-right-inline">Teo ZL, Jin L, Liu N, et al. Federated machine learning in healthcare: <span>A</span> systematic review on clinical applications and technical architecture. <em>Cell Reports Medicine</em>. 2024;5(2):101419. doi:<a href="https://doi.org/10.1016/j.xcrm.2024.101419">10.1016/j.xcrm.2024.101419</a></div>
</div>
<div id="ref-healthri2024agreements" class="csl-entry" role="listitem">
<div class="csl-left-margin">19. </div><div class="csl-right-inline">Health-RI. Agreements on the <span>National Health Data Infrastructure</span> for <span>Research</span>, <span>Policy</span> and <span>Innovation</span> - <span class="nocase">Health-RI Nationale Gezondheidsdata-infrastructuur</span> - <span>Confluence</span>. January 29, 2024. Accessed June 3, 2024. <a href="https://health-ri.atlassian.net/wiki/spaces/HNG/pages/249073646/Agreements+on+the+National+Health+Data+Infrastructure+for+Research+Policy+and+Innovation">https://health-ri.atlassian.net/wiki/spaces/HNG/pages/249073646/Agreements+on+the+National+Health+Data+Infrastructure+for+Research+Policy+and+Innovation</a></div>
</div>
<div id="ref-khalid2021standardized" class="csl-entry" role="listitem">
<div class="csl-left-margin">20. </div><div class="csl-right-inline">Khalid S, Yang C, Blacketer C, et al. A standardized analytics pipeline for reliable and rapid development and validation of prediction models using observational health data. <em>Computer Methods and Programs in Biomedicine</em>. 2021;211:106394. doi:<a href="https://doi.org/10.1016/j.cmpb.2021.106394">10.1016/j.cmpb.2021.106394</a></div>
</div>
<div id="ref-lee2022feedernet" class="csl-entry" role="listitem">
<div class="csl-left-margin">21. </div><div class="csl-right-inline">Lee S, Kim C, Chang J, Park RW. <span>FeederNet</span> (<span>Federated E-Health Big Data</span> for <span>Evidence Renovation Network</span>) platform in <span>Korea</span> – <span>OHDSI</span>. 2022. Accessed June 4, 2024. <a href="https://www.ohdsi.org/2022showcase-33/">https://www.ohdsi.org/2022showcase-33/</a></div>
</div>
<div id="ref-mateus2024data" class="csl-entry" role="listitem">
<div class="csl-left-margin">22. </div><div class="csl-right-inline">Mateus P, Moonen J, Beran M, et al. Data harmonization and federated learning for multi-cohort dementia research using the <span>OMOP</span> common data model: <span>A Netherlands</span> consortium of dementia cohorts case study. <em>Journal of Biomedical Informatics</em>. 2024;155:104661. doi:<a href="https://doi.org/10.1016/j.jbi.2024.104661">10.1016/j.jbi.2024.104661</a></div>
</div>
<div id="ref-kroes2022blueprint" class="csl-entry" role="listitem">
<div class="csl-left-margin">23. </div><div class="csl-right-inline">Kroes JA, Bansal AT, Berret E, et al. Blueprint for harmonising unstandardised disease registries to allow federated data analysis: Prepare for the future. <em>ERJ Open Research</em>. 2022;8(4). doi:<a href="https://doi.org/10.1183/23120541.00168-2022">10.1183/23120541.00168-2022</a></div>
</div>
<div id="ref-deltomme2024federated" class="csl-entry" role="listitem">
<div class="csl-left-margin">24. </div><div class="csl-right-inline">Deltomme C, Denturck K, De Jaeger P, et al. Federated <span>Health Innovation Network</span> (<span>FHIN</span>). Published online September 20, 2024. <a href="https://www.ohdsi-europe.org/images/symposium-2024/Posters/poster%20OHDSI%20FHIN%20Camille%20Deltomme%20-%20Camille%20Deltomme.pdf">https://www.ohdsi-europe.org/images/symposium-2024/Posters/poster%20OHDSI%20FHIN%20Camille%20Deltomme%20-%20Camille%20Deltomme.pdf</a></div>
</div>
<div id="ref-choudhury2020personal" class="csl-entry" role="listitem">
<div class="csl-left-margin">25. </div><div class="csl-right-inline">Choudhury A, van Soest J, Nayak S, Dekker A. Personal <span>Health Train</span> on <span>FHIR</span>: <span>A Privacy Preserving Federated Approach</span> for <span>Analyzing FAIR Data</span> in <span>Healthcare</span>. In: Bhattacharjee A, Borgohain SKr, Soni B, Verma G, Gao XZ, eds. <em>Machine <span>Learning</span>, <span>Image Processing</span>, <span>Network Security</span> and <span>Data Sciences</span></em>. Communications in <span>Computer</span> and <span>Information Science</span>. Springer; 2020:85-95. doi:<a href="https://doi.org/10.1007/978-981-15-6315-7_7">10.1007/978-981-15-6315-7_7</a></div>
</div>
<div id="ref-smits2022improved" class="csl-entry" role="listitem">
<div class="csl-left-margin">26. </div><div class="csl-right-inline">Smits D, Van Beusekom B, Martin F, Veen L, Geleijnse G, Moncada-Torres A. An <span>Improved Infrastructure</span> for <span>Privacy-Preserving Analysis</span> of <span>Patient Data</span>. In: Mantas J, Gallos P, Zoulias E, et al., eds. <em>Studies in <span>Health Technology</span> and <span>Informatics</span></em>. IOS Press; 2022. doi:<a href="https://doi.org/10.3233/SHTI220682">10.3233/SHTI220682</a></div>
</div>
<div id="ref-mullie2023coda" class="csl-entry" role="listitem">
<div class="csl-left-margin">27. </div><div class="csl-right-inline">Mullie L, Afilalo J, Archambault P, et al. <span>CODA</span>: An open-source platform for federated analysis and machine learning on distributed healthcare data. <em>Journal of the American Medical Informatics Association</em>. Published online December 21, 2023:ocad235. doi:<a href="https://doi.org/10.1093/jamia/ocad235">10.1093/jamia/ocad235</a></div>
</div>
<div id="ref-sinaci2024privacypreserving" class="csl-entry" role="listitem">
<div class="csl-left-margin">28. </div><div class="csl-right-inline">Sinaci AA, Gencturk M, Alvarez-Romero C, et al. Privacy-preserving federated machine learning on <span>FAIR</span> health data: <span>A</span> real-world application. <em>Computational and Structural Biotechnology Journal</em>. 2024;24:136-145. doi:<a href="https://doi.org/10.1016/j.csbj.2024.02.014">10.1016/j.csbj.2024.02.014</a></div>
</div>
<div id="ref-gruendner2019ketos" class="csl-entry" role="listitem">
<div class="csl-left-margin">29. </div><div class="csl-right-inline">Gruendner J, Schwachhofer T, Sippl P, et al. <span>KETOS</span>: <span>Clinical</span> decision support and machine learning as a service – <span>A</span> training and deployment platform based on <span>Docker</span>, <span>OMOP-CDM</span>, and <span>FHIR Web Services</span>. <em>PLOS ONE</em>. 2019;14(10):e0223010. doi:<a href="https://doi.org/10.1371/journal.pone.0223010">10.1371/journal.pone.0223010</a></div>
</div>
<div id="ref-cremonesi2023need" class="csl-entry" role="listitem">
<div class="csl-left-margin">30. </div><div class="csl-right-inline">Cremonesi F, Planat V, Kalokyri V, et al. The need for multimodal health data modeling: <span>A</span> practical approach for a federated-learning healthcare platform. <em>Journal of Biomedical Informatics</em>. 2023;141:104338. doi:<a href="https://doi.org/10.1016/j.jbi.2023.104338">10.1016/j.jbi.2023.104338</a></div>
</div>
<div id="ref-peng2023etlprocess" class="csl-entry" role="listitem">
<div class="csl-left-margin">31. </div><div class="csl-right-inline">Peng Y, Henke E, Reinecke I, Zoch M, Sedlmayr M, Bathelt F. An <span class="nocase">ETL-process</span> design for data harmonization to participate in international research with <span>German</span> real-world data based on <span>FHIR</span> and <span>OMOP CDM</span>. <em>International Journal of Medical Informatics</em>. 2023;169:104925. doi:<a href="https://doi.org/10.1016/j.ijmedinf.2022.104925">10.1016/j.ijmedinf.2022.104925</a></div>
</div>
<div id="ref-omoponfhir" class="csl-entry" role="listitem">
<div class="csl-left-margin">32. </div><div class="csl-right-inline"><span>OMOPonFHIR</span>. Accessed September 20, 2024. <a href="https://omoponfhir.org/">https://omoponfhir.org/</a></div>
</div>
<div id="ref-hai2023data" class="csl-entry" role="listitem">
<div class="csl-left-margin">33. </div><div class="csl-right-inline">Hai R, Koutras C, Quix C, Jarke M. Data <span>Lakes</span>: <span>A Survey</span> of <span>Functions</span> and <span>Systems</span>. <em>IEEE Transactions on Knowledge and Data Engineering</em>. 2023;35(12):12571-12590. doi:<a href="https://doi.org/10.1109/TKDE.2023.3270101">10.1109/TKDE.2023.3270101</a></div>
</div>
<div id="ref-harby2022data" class="csl-entry" role="listitem">
<div class="csl-left-margin">34. </div><div class="csl-right-inline">Harby AA, Zulkernine F. From <span>Data Warehouse</span> to <span>Lakehouse</span>: <span>A Comparative Review</span>. In: <em>2022 <span>IEEE International Conference</span> on <span>Big Data</span> (<span>Big Data</span>)</em>. IEEE; 2022:389-395. doi:<a href="https://doi.org/10.1109/BigData55660.2022.10020719">10.1109/BigData55660.2022.10020719</a></div>
</div>
<div id="ref-harby2024data" class="csl-entry" role="listitem">
<div class="csl-left-margin">35. </div><div class="csl-right-inline">Harby AA, Zulkernine F. Data <span>Lakehouse</span>: <span>A Survey</span> and <span>Experimental Study</span>. doi:<a href="https://doi.org/10.2139/ssrn.4765588">10.2139/ssrn.4765588</a></div>
</div>
<div id="ref-pedreira2023composable" class="csl-entry" role="listitem">
<div class="csl-left-margin">36. </div><div class="csl-right-inline">Pedreira P, Erling O, Karanasos K, et al. The <span>Composable Data Management System Manifesto</span>. <em>Proc VLDB Endow</em>. 2023;16(10):2679-2685. doi:<a href="https://doi.org/10.14778/3603581.3603604">10.14778/3603581.3603604</a></div>
</div>
<div id="ref-armbrust2021lakehouse" class="csl-entry" role="listitem">
<div class="csl-left-margin">37. </div><div class="csl-right-inline">Armbrust M, Ghodsi A, Xin R, Zaharia M. Lakehouse: <span>A New Generation</span> of <span>Open Platforms</span> that <span>Unify Data Warehousing</span> and <span>Advanced Analytics</span>. In:; 2021:8.</div>
</div>
<div id="ref-apache-arrow" class="csl-entry" role="listitem">
<div class="csl-left-margin">38. </div><div class="csl-right-inline"><em>Apache <span>Arrow</span></em>.; 2024. Accessed September 20, 2024. <a href="https://arrow.apache.org/">https://arrow.apache.org/</a></div>
</div>
<div id="ref-apache-parquet" class="csl-entry" role="listitem">
<div class="csl-left-margin">39. </div><div class="csl-right-inline"><em>Apache <span>Parquet</span></em>.; 2024. Accessed September 20, 2024. <a href="https://parquet.apache.org/">https://parquet.apache.org/</a></div>
</div>
<div id="ref-jain2023analyzing" class="csl-entry" role="listitem">
<div class="csl-left-margin">40. </div><div class="csl-right-inline">Jain P, Kraft P, Power C, Das T, Stoica I, Zaharia M. Analyzing and <span>Comparing Lakehouse Storage Systems</span>. Published online 2023.</div>
</div>
<div id="ref-apache-iceberg" class="csl-entry" role="listitem">
<div class="csl-left-margin">41. </div><div class="csl-right-inline"><em>Apache <span>Iceberg</span></em>. Accessed September 20, 2024. <a href="https://iceberg.apache.org/">https://iceberg.apache.org/</a></div>
</div>
<div id="ref-karamagi2022ehealth" class="csl-entry" role="listitem">
<div class="csl-left-margin">42. </div><div class="csl-right-inline">Karamagi HC, Muneene D, Droti B, et al. <span class="nocase">eHealth</span> or e-<span>Chaos</span>: <span>The</span> use of <span>Digital Health Interventions</span> for <span>Health Systems Strengthening</span> in sub-<span>Saharan Africa</span> over the last 10 years: <span>A</span> scoping review. <em>J Glob Health</em>. 2022;12:04090. doi:<a href="https://doi.org/10.7189/jogh.12.04090">10.7189/jogh.12.04090</a></div>
</div>
<div id="ref-mehl2023fullstac" class="csl-entry" role="listitem">
<div class="csl-left-margin">43. </div><div class="csl-right-inline">Mehl GL, Seneviratne MG, Berg ML, et al. A full-<span>STAC</span> remedy for global digital health transformation: Open standards, technologies, architectures and content. <em>Oxford Open Digital Health</em>. 2023;1:oqad018. doi:<a href="https://doi.org/10.1093/oodh/oqad018">10.1093/oodh/oqad018</a></div>
</div>
<div id="ref-openhie" class="csl-entry" role="listitem">
<div class="csl-left-margin">44. </div><div class="csl-right-inline"><em><span>OpenHIE Framework</span> V5.2-En</em>.; 2024. Accessed August 27, 2024. <a href="https://ohie.org/">https://ohie.org/</a></div>
</div>
<div id="ref-mamuye2022health" class="csl-entry" role="listitem">
<div class="csl-left-margin">45. </div><div class="csl-right-inline">Mamuye AL, Yilma TM, Abdulwahab A, et al. Health information exchange policy and standards for digital health systems in africa: <span>A</span> systematic review. <em>PLOS Digital Health</em>. 2022;1(10):e0000118. doi:<a href="https://doi.org/10.1371/journal.pdig.0000118">10.1371/journal.pdig.0000118</a></div>
</div>
<div id="ref-dalhatu2023paper" class="csl-entry" role="listitem">
<div class="csl-left-margin">46. </div><div class="csl-right-inline">Dalhatu I, Aniekwe C, Bashorun A, et al. From <span>Paper Files</span> to <span>Web-Based Application</span> for <span>Data-Driven Monitoring</span> of <span>HIV Programs</span>: <span>Nigeria</span>’s <span>Journey</span> to a <span>National Data Repository</span> for <span>Decision-Making</span> and <span>Patient Care</span>. <em>Methods Inf Med</em>. 2023;62(03/04):130-139. doi:<a href="https://doi.org/10.1055/s-0043-1768711">10.1055/s-0043-1768711</a></div>
</div>
<div id="ref-thaiya2021adoption" class="csl-entry" role="listitem">
<div class="csl-left-margin">47. </div><div class="csl-right-inline">Thaiya MS, Julia K, Joram M, Benard M, Nambiro DA. Adoption of <span>ICT</span> to <span>Enhance Access</span> to <span>Healthcare</span> in <span>Kenya</span>. <em>IOSR-JCE</em>. 2021;23(2):45-50.</div>
</div>
<div id="ref-nsaghurwe2021one" class="csl-entry" role="listitem">
<div class="csl-left-margin">48. </div><div class="csl-right-inline">Nsaghurwe A, Dwivedi V, Ndesanjo W, et al. One country’s journey to interoperability: <span>Tanzania</span>’s experience developing and implementing a national health information exchange. <em>BMC Medical Informatics and Decision Making</em>. 2021;21(1):139. doi:<a href="https://doi.org/10.1186/s12911-021-01499-6">10.1186/s12911-021-01499-6</a></div>
</div>
<div id="ref-hapi-fhir" class="csl-entry" role="listitem">
<div class="csl-left-margin">49. </div><div class="csl-right-inline"><span>HAPI FHIR</span> - <span>The Open Source FHIR API</span> for <span>Java</span>. Accessed September 20, 2024. <a href="https://hapifhir.io/">https://hapifhir.io/</a></div>
</div>
<div id="ref-syzdykova2017opensource" class="csl-entry" role="listitem">
<div class="csl-left-margin">50. </div><div class="csl-right-inline">Syzdykova A, Malta A, Zolfo M, Diro E, Oliveira JL. Open-<span>Source Electronic Health Record Systems</span> for <span>Low-Resource Settings</span>: <span>Systematic Review</span>. <em>JMIR Medical Informatics</em>. 2017;5(4):e44. doi:<a href="https://doi.org/10.2196/medinform.8131">10.2196/medinform.8131</a></div>
</div>
<div id="ref-mehl2020open" class="csl-entry" role="listitem">
<div class="csl-left-margin">51. </div><div class="csl-right-inline">Mehl G. Open <span>Smart Register Platform</span> (<span>OpenSRP</span>). <em>OpenSRP</em>. 2020;5:42-43. Accessed January 21, 2023. <a href="https://lib.digitalsquare.io/handle/123456789/77592">https://lib.digitalsquare.io/handle/123456789/77592</a></div>
</div>
<div id="ref-open-health-stack" class="csl-entry" role="listitem">
<div class="csl-left-margin">52. </div><div class="csl-right-inline">Open <span>Health Stack</span>. Accessed September 20, 2024. <a href="https://developers.google.com/open-health-stack">https://developers.google.com/open-health-stack</a></div>
</div>
<div id="ref-summitinstitutefordevelopment2023bunda" class="csl-entry" role="listitem">
<div class="csl-left-margin">53. </div><div class="csl-right-inline">Development SI for. <span>BUNDA App</span>. May 9, 2023. Accessed January 18, 2024. <a href="https://www.sid-indonesia.org/post/bunda-app">https://www.sid-indonesia.org/post/bunda-app</a></div>
</div>
<div id="ref-kurniawan2019midwife" class="csl-entry" role="listitem">
<div class="csl-left-margin">54. </div><div class="csl-right-inline">Kurniawan K, FitriaSyah I, Jayakusuma AR, et al. Midwife service coverage, quality of work, and client health improved after deployment of an <span class="nocase">OpenSRP-driven</span> client management application in <span>Indonesia</span>. In: Atlantis Press; 2019:155-162. doi:<a href="https://doi.org/10.2991/ichs-18.2019.21">10.2991/ichs-18.2019.21</a></div>
</div>
<div id="ref-clickhouse" class="csl-entry" role="listitem">
<div class="csl-left-margin">55. </div><div class="csl-right-inline">ClickHouse. Clickhouse: <span>Fast Open-Source OLAP DBMS</span>. Accessed September 20, 2024. <a href="https://clickhouse.com">https://clickhouse.com</a></div>
</div>
<div id="ref-dbt" class="csl-entry" role="listitem">
<div class="csl-left-margin">56. </div><div class="csl-right-inline">Dbt. Accessed September 20, 2024. <a href="https://www.getdbt.com/index">https://www.getdbt.com/index</a></div>
</div>
<div id="ref-estrin2010health" class="csl-entry" role="listitem">
<div class="csl-left-margin">57. </div><div class="csl-right-inline">Estrin D, Sim I. Health care delivery. <span class="nocase">Open mHealth</span> architecture: An engine for health care innovation. <em>Science</em>. 2010;330(6005):759-760. doi:<a href="https://doi.org/10.1126/science.1196187">10.1126/science.1196187</a></div>
</div>
<div id="ref-beck2019hourglass" class="csl-entry" role="listitem">
<div class="csl-left-margin">58. </div><div class="csl-right-inline">Beck M. On the hourglass model. <em>Communications of the ACM</em>. 2019;62(7):48-57. doi:<a href="https://doi.org/10.1145/3274770">10.1145/3274770</a></div>
</div>
<div id="ref-digitalpublicgoods" class="csl-entry" role="listitem">
<div class="csl-left-margin">59. </div><div class="csl-right-inline">Digital <span>Public Goods Alliance</span>. 2024. Accessed February 5, 2024. <a href="https://digitalpublicgoods.net/">https://digitalpublicgoods.net/</a></div>
</div>
<div id="ref-instant-openhie-v2" class="csl-entry" role="listitem">
<div class="csl-left-margin">60. </div><div class="csl-right-inline">Instant <span>OpenHIE</span> V2. Published online July 3, 2024. Accessed September 20, 2024. <a href="https://jembi.gitbook.io/instant-v2/">https://jembi.gitbook.io/instant-v2/</a></div>
</div>
</div></section></div></main>
<!-- /main column -->
<script id="quarto-html-after-body" type="application/javascript">
window.document.addEventListener("DOMContentLoaded", function (event) {
const toggleBodyColorMode = (bsSheetEl) => {
const mode = bsSheetEl.getAttribute("data-mode");
const bodyEl = window.document.querySelector("body");
if (mode === "dark") {
bodyEl.classList.add("quarto-dark");
bodyEl.classList.remove("quarto-light");
} else {
bodyEl.classList.add("quarto-light");
bodyEl.classList.remove("quarto-dark");
}
}
const toggleBodyColorPrimary = () => {
const bsSheetEl = window.document.querySelector("link#quarto-bootstrap");
if (bsSheetEl) {
toggleBodyColorMode(bsSheetEl);
}
}
toggleBodyColorPrimary();
const icon = "";
const anchorJS = new window.AnchorJS();
anchorJS.options = {
placement: 'right',
icon: icon
};
anchorJS.add('.anchored');
const isCodeAnnotation = (el) => {
for (const clz of el.classList) {
if (clz.startsWith('code-annotation-')) {
return true;
}
}
return false;
}
const clipboard = new window.ClipboardJS('.code-copy-button', {
text: function(trigger) {
const codeEl = trigger.previousElementSibling.cloneNode(true);
for (const childEl of codeEl.children) {
if (isCodeAnnotation(childEl)) {
childEl.remove();
}
}
return codeEl.innerText;
}
});
clipboard.on('success', function(e) {
// button target
const button = e.trigger;
// don't keep focus
button.blur();
// flash "checked"
button.classList.add('code-copy-button-checked');
var currentTitle = button.getAttribute("title");
button.setAttribute("title", "Copied!");
let tooltip;
if (window.bootstrap) {
button.setAttribute("data-bs-toggle", "tooltip");
button.setAttribute("data-bs-placement", "left");
button.setAttribute("data-bs-title", "Copied!");
tooltip = new bootstrap.Tooltip(button,
{ trigger: "manual",
customClass: "code-copy-button-tooltip",
offset: [0, -8]});
tooltip.show();
}
setTimeout(function() {
if (tooltip) {
tooltip.hide();
button.removeAttribute("data-bs-title");
button.removeAttribute("data-bs-toggle");
button.removeAttribute("data-bs-placement");
}
button.setAttribute("title", currentTitle);
button.classList.remove('code-copy-button-checked');
}, 1000);
// clear code selection
e.clearSelection();
});
var localhostRegex = new RegExp(/^(?:http|https):\/\/localhost\:?[0-9]*\//);
var mailtoRegex = new RegExp(/^mailto:/);
var filterRegex = new RegExp('/' + window.location.host + '/');
var isInternal = (href) => {
return filterRegex.test(href) || localhostRegex.test(href) || mailtoRegex.test(href);
}
// Inspect non-navigation links and adorn them if external
var links = window.document.querySelectorAll('a[href]:not(.nav-link):not(.navbar-brand):not(.toc-action):not(.sidebar-link):not(.sidebar-item-toggle):not(.pagination-link):not(.no-external):not([aria-hidden]):not(.dropdown-item):not(.quarto-navigation-tool)');
for (var i=0; i<links.length; i++) {
const link = links[i];
if (!isInternal(link.href)) {
// undo the damage that might have been done by quarto-nav.js in the case of
// links that we want to consider external
if (link.dataset.originalHref !== undefined) {
link.href = link.dataset.originalHref;
}
}
}
function tippyHover(el, contentFn, onTriggerFn, onUntriggerFn) {
const config = {
allowHTML: true,
maxWidth: 500,
delay: 100,
arrow: false,
appendTo: function(el) {
return el.parentElement;
},
interactive: true,
interactiveBorder: 10,
theme: 'quarto',
placement: 'bottom-start',
};
if (contentFn) {
config.content = contentFn;
}
if (onTriggerFn) {
config.onTrigger = onTriggerFn;
}
if (onUntriggerFn) {
config.onUntrigger = onUntriggerFn;
}
window.tippy(el, config);
}
const noterefs = window.document.querySelectorAll('a[role="doc-noteref"]');
for (var i=0; i<noterefs.length; i++) {
const ref = noterefs[i];
tippyHover(ref, function() {
// use id or data attribute instead here
let href = ref.getAttribute('data-footnote-href') || ref.getAttribute('href');
try { href = new URL(href).hash; } catch {}
const id = href.replace(/^#\/?/, "");
const note = window.document.getElementById(id);
if (note) {
return note.innerHTML;
} else {
return "";
}
});
}
const xrefs = window.document.querySelectorAll('a.quarto-xref');
const processXRef = (id, note) => {
// Strip column container classes
const stripColumnClz = (el) => {
el.classList.remove("page-full", "page-columns");
if (el.children) {
for (const child of el.children) {
stripColumnClz(child);
}
}
}
stripColumnClz(note)
if (id === null || id.startsWith('sec-')) {
// Special case sections, only their first couple elements
const container = document.createElement("div");
if (note.children && note.children.length > 2) {
container.appendChild(note.children[0].cloneNode(true));
for (let i = 1; i < note.children.length; i++) {
const child = note.children[i];
if (child.tagName === "P" && child.innerText === "") {
continue;
} else {
container.appendChild(child.cloneNode(true));
break;
}
}
if (window.Quarto?.typesetMath) {
window.Quarto.typesetMath(container);
}
return container.innerHTML
} else {
if (window.Quarto?.typesetMath) {
window.Quarto.typesetMath(note);
}
return note.innerHTML;
}
} else {
// Remove any anchor links if they are present
const anchorLink = note.querySelector('a.anchorjs-link');
if (anchorLink) {
anchorLink.remove();
}
if (window.Quarto?.typesetMath) {
window.Quarto.typesetMath(note);
}
// TODO in 1.5, we should make sure this works without a callout special case
if (note.classList.contains("callout")) {
return note.outerHTML;
} else {
return note.innerHTML;
}
}
}
for (var i=0; i<xrefs.length; i++) {
const xref = xrefs[i];
tippyHover(xref, undefined, function(instance) {
instance.disable();
let url = xref.getAttribute('href');
let hash = undefined;
if (url.startsWith('#')) {
hash = url;
} else {
try { hash = new URL(url).hash; } catch {}
}
if (hash) {
const id = hash.replace(/^#\/?/, "");
const note = window.document.getElementById(id);
if (note !== null) {
try {
const html = processXRef(id, note.cloneNode(true));
instance.setContent(html);
} finally {
instance.enable();
instance.show();
}
} else {
// See if we can fetch this
fetch(url.split('#')[0])
.then(res => res.text())
.then(html => {
const parser = new DOMParser();
const htmlDoc = parser.parseFromString(html, "text/html");
const note = htmlDoc.getElementById(id);
if (note !== null) {
const html = processXRef(id, note);
instance.setContent(html);
}
}).finally(() => {
instance.enable();
instance.show();
});
}
} else {
// See if we can fetch a full url (with no hash to target)
// This is a special case and we should probably do some content thinning / targeting
fetch(url)
.then(res => res.text())
.then(html => {
const parser = new DOMParser();
const htmlDoc = parser.parseFromString(html, "text/html");
const note = htmlDoc.querySelector('main.content');
if (note !== null) {
// This should only happen for chapter cross references
// (since there is no id in the URL)
// remove the first header
if (note.children.length > 0 && note.children[0].tagName === "HEADER") {
note.children[0].remove();
}
const html = processXRef(null, note);
instance.setContent(html);
}
}).finally(() => {
instance.enable();
instance.show();
});
}
}, function(instance) {
});
}
let selectedAnnoteEl;
const selectorForAnnotation = ( cell, annotation) => {
let cellAttr = 'data-code-cell="' + cell + '"';
let lineAttr = 'data-code-annotation="' + annotation + '"';
const selector = 'span[' + cellAttr + '][' + lineAttr + ']';
return selector;
}
const selectCodeLines = (annoteEl) => {
const doc = window.document;
const targetCell = annoteEl.getAttribute("data-target-cell");
const targetAnnotation = annoteEl.getAttribute("data-target-annotation");
const annoteSpan = window.document.querySelector(selectorForAnnotation(targetCell, targetAnnotation));
const lines = annoteSpan.getAttribute("data-code-lines").split(",");
const lineIds = lines.map((line) => {
return targetCell + "-" + line;
})
let top = null;
let height = null;
let parent = null;
if (lineIds.length > 0) {
//compute the position of the single el (top and bottom and make a div)
const el = window.document.getElementById(lineIds[0]);
top = el.offsetTop;
height = el.offsetHeight;
parent = el.parentElement.parentElement;
if (lineIds.length > 1) {
const lastEl = window.document.getElementById(lineIds[lineIds.length - 1]);
const bottom = lastEl.offsetTop + lastEl.offsetHeight;
height = bottom - top;
}
if (top !== null && height !== null && parent !== null) {
// cook up a div (if necessary) and position it
let div = window.document.getElementById("code-annotation-line-highlight");
if (div === null) {
div = window.document.createElement("div");
div.setAttribute("id", "code-annotation-line-highlight");
div.style.position = 'absolute';
parent.appendChild(div);
}
div.style.top = top - 2 + "px";
div.style.height = height + 4 + "px";
div.style.left = 0;
let gutterDiv = window.document.getElementById("code-annotation-line-highlight-gutter");
if (gutterDiv === null) {
gutterDiv = window.document.createElement("div");
gutterDiv.setAttribute("id", "code-annotation-line-highlight-gutter");
gutterDiv.style.position = 'absolute';
const codeCell = window.document.getElementById(targetCell);
const gutter = codeCell.querySelector('.code-annotation-gutter');
gutter.appendChild(gutterDiv);
}
gutterDiv.style.top = top - 2 + "px";
gutterDiv.style.height = height + 4 + "px";
}
selectedAnnoteEl = annoteEl;
}
};
const unselectCodeLines = () => {
const elementsIds = ["code-annotation-line-highlight", "code-annotation-line-highlight-gutter"];
elementsIds.forEach((elId) => {
const div = window.document.getElementById(elId);
if (div) {
div.remove();
}
});
selectedAnnoteEl = undefined;
};
// Handle positioning of the toggle
window.addEventListener(
"resize",
throttle(() => {
elRect = undefined;
if (selectedAnnoteEl) {
selectCodeLines(selectedAnnoteEl);
}
}, 10)
);
function throttle(fn, ms) {
let throttle = false;
let timer;
return (...args) => {
if(!throttle) { // first call gets through
fn.apply(this, args);
throttle = true;
} else { // all the others get throttled
if(timer) clearTimeout(timer); // cancel #2
timer = setTimeout(() => {
fn.apply(this, args);
timer = throttle = false;
}, ms);
}
};
}
// Attach click handler to the DT
const annoteDls = window.document.querySelectorAll('dt[data-target-cell]');
for (const annoteDlNode of annoteDls) {
annoteDlNode.addEventListener('click', (event) => {
const clickedEl = event.target;
if (clickedEl !== selectedAnnoteEl) {
unselectCodeLines();
const activeEl = window.document.querySelector('dt[data-target-cell].code-annotation-active');
if (activeEl) {
activeEl.classList.remove('code-annotation-active');
}
selectCodeLines(clickedEl);
clickedEl.classList.add('code-annotation-active');
} else {
// Unselect the line
unselectCodeLines();
clickedEl.classList.remove('code-annotation-active');
}
});
}
const findCites = (el) => {
const parentEl = el.parentElement;
if (parentEl) {
const cites = parentEl.dataset.cites;
if (cites) {
return {
el,
cites: cites.split(' ')
};
} else {
return findCites(el.parentElement)
}
} else {
return undefined;
}
};
var bibliorefs = window.document.querySelectorAll('a[role="doc-biblioref"]');
for (var i=0; i<bibliorefs.length; i++) {
const ref = bibliorefs[i];
const citeInfo = findCites(ref);
if (citeInfo) {
tippyHover(citeInfo.el, function() {
var popup = window.document.createElement('div');
citeInfo.cites.forEach(function(cite) {
var citeDiv = window.document.createElement('div');
citeDiv.classList.add('hanging-indent');
citeDiv.classList.add('csl-entry');
var biblioDiv = window.document.getElementById('ref-' + cite);
if (biblioDiv) {
citeDiv.innerHTML = biblioDiv.innerHTML;
}
popup.appendChild(citeDiv);
});
return popup.innerHTML;
});
}
}
});
</script>
</div> <!-- /content -->
</body></html>