-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathindex.html
1362 lines (1328 loc) · 112 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
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!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="Julie Fleischer">
<meta name="author" content="Irni Gemzon">
<meta name="author" content="Chris Ihure">
<meta name="author" content="Steven Wanyee">
<meta name="author" content="Alessandro Pietrobon">
<meta name="author" content="Ryan Chrichton">
<meta name="author" content="John Grimes">
<meta name="keywords" content="Analytics-on-FHIR, SQL-on-FHIR, HIE, data platforms, LMICs, digital health">
<title>Design and implemention of open health data systems with standardized data and analytics capabilities for low- and middle income countries</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;
margin-bottom: 0em;
}
.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>
<li><a href="#sec-introduction" id="toc-sec-introduction" class="nav-link active" data-scroll-target="#sec-introduction">Introduction</a>
<ul class="collapse">
<li><a href="#the-need-for-standardized-open-health-data-systems" id="toc-the-need-for-standardized-open-health-data-systems" class="nav-link" data-scroll-target="#the-need-for-standardized-open-health-data-systems">The need for standardized open health data systems</a></li>
<li><a href="#data-analytics-functions-are-essential-in-open-health-data-systems" id="toc-data-analytics-functions-are-essential-in-open-health-data-systems" class="nav-link" data-scroll-target="#data-analytics-functions-are-essential-in-open-health-data-systems">Data & analytics functions are essential in open health data systems</a></li>
<li><a href="#objects-of-openness-in-secondary-data-sharing" id="toc-objects-of-openness-in-secondary-data-sharing" class="nav-link" data-scroll-target="#objects-of-openness-in-secondary-data-sharing">Objects of openness in secondary data sharing</a></li>
<li><a href="#outline" id="toc-outline" class="nav-link" data-scroll-target="#outline">Outline</a></li>
</ul></li>
<li><a href="#extending-openhie-to-include-modern-data-and-analytics-standards" id="toc-extending-openhie-to-include-modern-data-and-analytics-standards" class="nav-link" data-scroll-target="#extending-openhie-to-include-modern-data-and-analytics-standards">Extending OpenHIE to include modern data and analytics standards</a>
<ul class="collapse">
<li><a href="#high-level-solution-design" id="toc-high-level-solution-design" class="nav-link" data-scroll-target="#high-level-solution-design">High-level solution design</a></li>
<li><a href="#momcare-demonstrators" id="toc-momcare-demonstrators" class="nav-link" data-scroll-target="#momcare-demonstrators">Momcare demonstrators</a></li>
<li><a href="#evaluation-of-momcare-demonstrators" id="toc-evaluation-of-momcare-demonstrators" class="nav-link" data-scroll-target="#evaluation-of-momcare-demonstrators">Evaluation of Momcare demonstrators</a></li>
</ul></li>
<li><a href="#discussion" id="toc-discussion" class="nav-link" data-scroll-target="#discussion">Discussion</a>
<ul class="collapse">
<li><a href="#jembi-openhim-platform" id="toc-jembi-openhim-platform" class="nav-link" data-scroll-target="#jembi-openhim-platform">Jembi OpenHIM platform</a></li>
<li><a href="#ona-opensrp-2" id="toc-ona-opensrp-2" class="nav-link" data-scroll-target="#ona-opensrp-2">ONA OpenSRP 2</a></li>
<li><a href="#assessment-of-design-principles" id="toc-assessment-of-design-principles" class="nav-link" data-scroll-target="#assessment-of-design-principles">Assessment of design principles</a></li>
<li><a href="#limitation-and-future-work" id="toc-limitation-and-future-work" class="nav-link" data-scroll-target="#limitation-and-future-work">Limitation and future work</a></li>
</ul></li>
<li><a href="#conclusion" id="toc-conclusion" class="nav-link" data-scroll-target="#conclusion">Conclusion</a></li>
<li><a href="#acknowledgements" id="toc-acknowledgements" class="nav-link" data-scroll-target="#acknowledgements">Acknowledgements</a></li>
<li><a href="#conflicts-of-interest" id="toc-conflicts-of-interest" class="nav-link" data-scroll-target="#conflicts-of-interest">Conflicts of interest</a></li>
<li><a href="#abbreviations" id="toc-abbreviations" class="nav-link" data-scroll-target="#abbreviations">Abbreviations</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></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">Design and implemention of open health data systems with standardized data and analytics capabilities for low- and middle income countries</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">
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">Julie Fleischer </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
PharmAccess Foundation
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Irni Gemzon </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
PharmAccess Foundation
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Chris Ihure </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
PharmAccess Kenya
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Steven Wanyee </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
IntelliSOFT
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Alessandro Pietrobon </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
ONA
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">Ryan Chrichton </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Jembi Health Systems
</p>
</div>
<div class="quarto-title-meta-contents">
<p class="author">John Grimes </p>
</div>
<div class="quarto-title-meta-contents">
<p class="affiliation">
Australian e-Health Research Centre
</p>
</div>
</div>
<div class="quarto-title-meta">
</div>
<div>
<div class="abstract">
<div class="block-title">Abstract</div>
<p>TO DO: add abstract.</p>
</div>
</div>
<div>
<div class="keywords">
<div class="block-title">Keywords</div>
<p>Analytics-on-FHIR, SQL-on-FHIR, HIE, data platforms, LMICs, digital health</p>
</div>
</div>
</header>
<section id="sec-introduction" class="level2">
<h2 class="anchored" data-anchor-id="sec-introduction">Introduction</h2>
<section id="the-need-for-standardized-open-health-data-systems" class="level3">
<h3 class="anchored" data-anchor-id="the-need-for-standardized-open-health-data-systems">The need for standardized open health data systems</h3>
<p>Digital health systems in low- and middle income countries (LMICs) work, but they do not work together. Consider, for example, the current state of digital health in Kenya. It is common practice in health facilities to have two independent data entry systems within a department, acquire administrative and lab systems from different vendors, and for users to both generate reports at the facility and have the data entered manually into the national health information system <span class="citation" data-cites="muinga2020digital">(<a href="#ref-muinga2020digital" role="doc-biblioref">Muinga et al., 2020</a>)</span>. While political and provider willingness to invest in digital health systems is clear, the lack of integration between health information systems and the respective care flows provides a major challenge to harness its potential. Health system users describe a need for digital tools that would improve access to information in clinical settings to guide decisions and ensure timely and appropriate interventions in real time, enabling them to provide high quality care to their patients <span class="citation" data-cites="bartlett2021insights">(<a href="#ref-bartlett2021insights" role="doc-biblioref">Bartlett et al., 2021</a>)</span>. Yet the current digital landscape has even been coined as ‘echaos’, presenting as a large-scale uncoordinated implementation of digital health tools in Sub-Saharan Africa, with multiple overlapping solutions adding to the staff and resource burden of an already strained health care system <span class="citation" data-cites="karamagi2022ehealth">(<a href="#ref-karamagi2022ehealth" role="doc-biblioref">Karamagi et al., 2022</a>)</span>.</p>
<p>In the meantime, constraints to quality care remains a contributing factor in 90% of Kenya’s maternal deaths, with delays in treatment, inadequate clinical skills and insufficient monitoring cited as contributing factors in 33%, 28% and 27% of maternal death cases, respectively, and poor record keeping playing a role in the majority of cases (CHECK REFERENCE: Ministry of Health Kenya, 2017). Improving quality throughout the continuum of maternal healthcare has demonstrably been linked to better outcomes, and there is an opportunity for digital health systems to connect care <span class="citation" data-cites="ochieng2024exploring dennis2019initiation dohmen2022implementing">(<a href="#ref-dennis2019initiation" role="doc-biblioref">Dennis et al., 2019</a>; <a href="#ref-dohmen2022implementing" role="doc-biblioref">Dohmen et al., 2022</a>; <a href="#ref-ochieng2024exploring" role="doc-biblioref">Ochieng’ et al., 2024</a>)</span>. The digital landscape is not lacking in number, function, variety, and complexity of digital (maternal) health interventions; but it is lacking in connection and coordination. To date the global digital health ecosystem is still project-centric, resulting in data fragmentation and technology lock-in, compromising health care delivery <span class="citation" data-cites="mehl2023fullstac">(<a href="#ref-mehl2023fullstac" role="doc-biblioref">Mehl et al., 2023</a>)</span>. Digital technologies have the potential to increase the availability, accessibility, acceptability, and quality of health services; make healthcare more preventive, personalised, and mobile; and enfranchise patients and communities, particularly those who are most vulnerable <span class="citation" data-cites="kickbusch2021lancet">(<a href="#ref-kickbusch2021lancet" role="doc-biblioref">Kickbusch et al., 2021</a>)</span>.</p>
<p>To achieve scaleability of digital health interventions, we need to design and implement standardized open health data systems (OHDS) and their associated ecosystems that can support improvements in the wider health sector along five dimensions, namely <span class="citation" data-cites="kelley2020digital">(<a href="#ref-kelley2020digital" role="doc-biblioref">Kelley et al., 2020</a>)</span>:</p>
<ol type="1">
<li>overall quality and continuity of care;</li>
<li>adherence to clinical guidelines and best practices;</li>
<li>efficiency and affordability of services and health commodities, by reducing duplication of effort and ensuring effective use of time and resources;</li>
<li>health-financing models and processes, regulation, oversight, and patient safety resulting from increased availability of performance data and reductions in errors; and</li>
<li>health policy-making and resource allocation based on better quality data.</li>
</ol>
</section>
<section id="data-analytics-functions-are-essential-in-open-health-data-systems" class="level3">
<h3 class="anchored" data-anchor-id="data-analytics-functions-are-essential-in-open-health-data-systems">Data & analytics functions are essential in open health data systems</h3>
<p>From our experience in implementing digital health interventions, we have shown that improvements along the five aforementioned dimensions are within reach. In our MomCare programme, for example, we have demonstrated that routinely collected health data, combined with financial data, can be effectively used to gain insight into the continuity of care, improve clinical adherence whilst maintaining efficiency and affordability of health services in LMICs. By actively coaxing pregnant mothers to undergo 4 antenatal check-ups, outcomes were improved whilst maintaining the average cost of maternal, newborn and child health (MNCH) services <span class="citation" data-cites="huisman2022digital sanctis2022maintaining izudi2023experiences">(<a href="#ref-huisman2022digital" role="doc-biblioref">Huisman et al., 2022</a>; <a href="#ref-izudi2023experiences" role="doc-biblioref">Izudi et al., 2023</a>; <a href="#ref-sanctis2022maintaining" role="doc-biblioref">Sanctis et al., 2022</a>)</span>.</p>
<p>MomCare is critically dependent on the availability of data and analytics functions within its underlying supportive OHDS. For example, to implement the value-based healthcare business logic of MomCare, detailed analysis of patient journeys is required. This functionality is currently not available as a standard; standardized reports that are available, such as DHIS2, contained insufficient information and analytical functions to support intervention that aim to improve continuity of care and adherence to clinical guidelines. As such, a large part of the day-to-day operation of MomCare revolved performing data and analytics: data acquisition, data integration, analysis etc.</p>
<p>This situation is not unique to MomCare. In fact, many in the global digital health community think that data & analytics services should be an essential capibility of OHDSs going forward. This is exemplified how the OpenHIE reference architecture <span class="citation" data-cites="openhie">(<a href="#ref-openhie" role="doc-biblioref"><span>“<span>OpenHIE Framework</span> v5.2-en,”</span> 2024</a>)</span> has been adopted by many sub-Saharan African countries as the blueprint for implementing nation-wide health information exchanges (HIE) <span class="citation" data-cites="mamuye2022health">(<a href="#ref-mamuye2022health" role="doc-biblioref">Mamuye et al., 2022</a>)</span>, including Nigeria <span class="citation" data-cites="dalhatu2023paper">(<a href="#ref-dalhatu2023paper" role="doc-biblioref">Dalhatu et al., 2023</a>)</span>, Kenya <span class="citation" data-cites="mbugua2021adoption">(<a href="#ref-mbugua2021adoption" role="doc-biblioref">Mbugua et al., 2021</a>)</span> and Tanzania <span class="citation" data-cites="nsaghurwe2021one">(<a href="#ref-nsaghurwe2021one" role="doc-biblioref">Nsaghurwe et al., 2021</a>)</span>. These countries have, as a matter of course, extended the framework to include “data & analytics services” as an additional domain <span class="citation" data-cites="mbugua2021adoption dalhatu2023paper">(<a href="#ref-dalhatu2023paper" role="doc-biblioref">Dalhatu et al., 2023</a>; <a href="#ref-mbugua2021adoption" role="doc-biblioref">Mbugua et al., 2021</a>)</span>. In terms of the often-used distinction between primary and secondary health data use <span class="citation" data-cites="cascini2024health">(<a href="#ref-cascini2024health" role="doc-biblioref">Cascini et al., 2024</a>)</span>, these countries aim to extend OpenHIE beyond it original scope of primary data sharing to also include secondary use of health data as a functional requirement towards a learning health system <span class="citation" data-cites="witter2022learning">(<a href="#ref-witter2022learning" role="doc-biblioref">Witter et al., 2022</a>)</span>. If we are include secondary data use into the OpenHIE framework we need to extend the standards, technologies and architecture to include data & analytics functionality to do so. The lack of detailed specifications and consensus of this addition to OpenHIE currently stands in the way of development projects that aim to establish more comprehensive platforms to support primary and secondary health data sharing in LMICs.</p>
</section>
<section id="objects-of-openness-in-secondary-data-sharing" class="level3">
<h3 class="anchored" data-anchor-id="objects-of-openness-in-secondary-data-sharing">Objects of openness in secondary data sharing</h3>
<p>To set the scene for the main contributions of this viewpoint paper, consider four types of secondary data sharing as shown in <a href="#tbl-types-data-sharing" class="quarto-xref">Table 1</a>, where we follow the research agenda proposed by de Reuver et al. to scrutinize how openness of data platforms can be achieved <span class="citation" data-cites="dereuver2022openness">(<a href="#ref-dereuver2022openness" role="doc-biblioref">de Reuver et al., 2022</a>)</span>.</p>
<div id="tbl-types-data-sharing" class="striped hover responsive quarto-float anchored">
<figure class="quarto-float quarto-float-tbl figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-tbl" id="tbl-types-data-sharing-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Table 1: Types of secondary data sharing, and there relevance to the proposed extension of the OpenHIE specification.
</figcaption>
<div aria-describedby="tbl-types-data-sharing-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<div class="table-responsive">
<table class="table-striped table-hover table">
<colgroup>
<col style="width: 12%">
<col style="width: 32%">
<col style="width: 56%">
</colgroup>
<thead>
<tr class="header">
<th style="text-align: center;"></th>
<th style="text-align: left;"><strong>Type of data sharing</strong></th>
<th style="text-align: left;"><strong>Relevance to extension of OpenHIE specification</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;"><strong>1</strong></td>
<td style="text-align: left;">Data at the most granular level with which the patient journey (timeline) can be reconstructed and used for various analytic tasks.</td>
<td style="text-align: left;">The Shared Health Record (SHR) is specified as an operational, real-time transactional data source, distinct from a data warehouse. A seperate specification of data and analytics functions, typically provided by a datawarehouse, is required.</td>
</tr>
<tr class="even">
<td style="text-align: center;"><strong>2</strong></td>
<td style="text-align: left;">Aggregated data, typically used for routine reports and benchmarking.</td>
<td style="text-align: left;">The Health Management Information System (HMIS) already includes the Aggregate Data Exchange (ADX) workflow standard. Modern data & analytics standards can support more flexible and extensive workflows, such as are emerging based on FHIR.</td>
</tr>
<tr class="odd">
<td style="text-align: center;"><strong>3</strong></td>
<td style="text-align: left;">Data analytics modules, that provide secure and privacy-preserving computational environments to work with the data.</td>
<td style="text-align: left;">Federated learning (FL) <span class="citation" data-cites="rieke2020future">(<a href="#ref-rieke2020future" role="doc-biblioref">Rieke et al., 2020</a>)</span> and privacy- enhancing technologies (PETs) <span class="citation" data-cites="scheibner2021revolutionizing jordan2022selecting">(<a href="#ref-jordan2022selecting" role="doc-biblioref">Jordan et al., 2022</a>; <a href="#ref-scheibner2021revolutionizing" role="doc-biblioref">Scheibner et al., 2021</a>)</span> provide new paradigms that address the problem of data governance and privacy by training algorithms collaboratively without exchanging the data itself. Requires use of a common data model to analyze the data in a collaborative fashion.</td>
</tr>
<tr class="even">
<td style="text-align: center;"><strong>4</strong></td>
<td style="text-align: left;">Trained models that have been derived from the data and can be used stand-alone for decision support.</td>
<td style="text-align: left;">Increasing need to open source trained AI models <span class="citation" data-cites="osi2024open">(<a href="#ref-osi2024open" role="doc-biblioref"><span>“The <span>Open Source AI Definition</span> v0.0.9,”</span> 2024</a>)</span>, enabled by technologies such as ONNX <span class="citation" data-cites="onnx">(<a href="#ref-onnx" role="doc-biblioref"><span>“<span>ONNX</span> v1.15.0,”</span> 2023</a>)</span>.</td>
</tr>
</tbody>
</table>
</div>
</div>
</figure>
</div>
<p>[TO DO: add more text here to clarify our position and intention with this paper.]</p>
</section>
<section id="outline" class="level3">
<h3 class="anchored" data-anchor-id="outline">Outline</h3>
<p>The main contribution of this paper is to propose how recent standards and open source implementations from the data engineering & analytics community can be integrated into the OpenHIE framework. In the following, we first describe how the lakehouse design pattern, being the most widely used data & analytics solution architecture, can be integrated in OpenHIE. To demonstrate the feasibility of this design, we present a proof-of-concept impelementation using open source technologies within the context of the MomCare programme. Code and digital artifacts of this demonstrator are available as supplementary material [TO DO: include links to support GitHub repositories].</p>
<p>We take a narrative approach in presenting our design, surveying existing scientific studies on OHDSs, focusing on the seminal reports and subsequently searching forward citations. In addition, we have searched the open source repositories (most notably GitHub) and the online communities (OpenHIE community, FHIR community) to search for relevant open standards, technologies and architectures. This paper should not be considered as a proper systematic review.</p>
<p>Finally, we compare this solution design with two widely used and operational OpenHIE-compliant open source frameworks, namely the OpenHIM platform (<a href="https://jembi.gitbook.io/openhim-platform/">https://jembi.gitbook.io/openhim-platform/</a>) and the OnaData platform <a href="https://ona.io/home/products/ona-data/features/">https://ona.io/home/products/ona-data/features/</a>. We discuss our findings and propose routes for future development.</p>
<p>The main contributions of this paper are i) description of a framework for the components of the Data & Analysis Services that builds on current best practices from the data engineering community into the OpenHIE framework; and ii) evaluation of different implementations and design options for various data sharing scenarios within an extended OpenHIE architecture.</p>
</section>
</section>
<section id="extending-openhie-to-include-modern-data-and-analytics-standards" class="level2">
<h2 class="anchored" data-anchor-id="extending-openhie-to-include-modern-data-and-analytics-standards">Extending OpenHIE to include modern data and analytics standards</h2>
<section id="high-level-solution-design" class="level3">
<h3 class="anchored" data-anchor-id="high-level-solution-design">High-level solution design</h3>
<p>The original OpenHIE specification discerns four domains, namely Point-of-Service systems, the Interoperability Layer, Common Services and Business Services (<a href="#fig-ohie" class="quarto-xref">Figure 1</a>). We propose to extend the OpenHIE architecture with a “Data and Analytics Services” domain with different zones taken from the data lakehouse architecture, which currently is the most commonly used design pattern in this domain <span class="citation" data-cites="armbrust2021lakehouse hai2023data harby2022data harby2024data">(<a href="#ref-armbrust2021lakehouse" role="doc-biblioref">Armbrust et al., 2021</a>; <a href="#ref-hai2023data" role="doc-biblioref">Hai et al., 2023</a>; <a href="#ref-harby2024data" role="doc-biblioref">Harby and Zulkernine, 2024</a>, <a href="#ref-harby2022data" role="doc-biblioref">2022</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">Hai et al., 2023</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">Armbrust et al., 2021</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.</p>
<div id="fig-ohie" 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-ohie-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 1: Proposed extension of the OpenHIE architecture that includes “Data and Analytics Services” as an additional service domain.
</figcaption>
<div aria-describedby="fig-ohie-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="./images/openhie-extended-architecture.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>Following the terminology proposed by Hai et al. <span class="citation" data-cites="hai2023data">(<a href="#ref-hai2023data" role="doc-biblioref">Hai et al., 2023</a>)</span>, <a href="#fig-ohie" class="quarto-xref">Figure 1</a> summarizes how the different zones of the lakehouse architecture can be adapted for healthcare and integrated into the OpeHIE specification. Taking Fast Healthcare Interoperability Resources (FHIR) as the open data standard<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>, we envisage the extended OpenHIE architecture to include a ‘OpenHIE Lakehouse’ with the following healthcare specific adaptations of the various data & analytics services:</p>
<ul>
<li><strong>Ingestion Services:</strong> use of FHIR standard to harmonize all incoming healthcare data to a common data model, including metadata extraction and metadata modeling. Should support both single-records streaming ingest as well as bulk data ingestion in batches using the Bulk FHIR API as interface <span class="citation" data-cites="mandl2020push jones2021landscape">(<a href="#ref-jones2021landscape" role="doc-biblioref">Jones et al., 2021</a>; <a href="#ref-mandl2020push" role="doc-biblioref">Mandl et al., 2020</a>)</span>.</li>
<li><strong>Storage Service:</strong> should support columnar storage engines optimized for analytical workloads. In case of file-based storage, use columnar file formats such as Apache Parquet. In case of databases, prefer open source engines such as Clickhouse or PostgreSQL that also support external, file-based tabels <span class="citation" data-cites="pedreira2023composable">(<a href="#ref-pedreira2023composable" role="doc-biblioref">Pedreira et al., 2023</a>)</span>.</li>
<li><strong>Maintenance:</strong> use one of the open table formats such as Apache Iceberg, Apache Hudi and/or Delta Lake <span class="citation" data-cites="jain2023analyzing">(<a href="#ref-jain2023analyzing" role="doc-biblioref">Jain et al., 2023</a>)</span> to realize dataset organization, data integration, schema evolution and data provenance. Use of SQL-on-FHIR v2 View definitions to facilitate access to FHIR resources in flattened, tabular format <span class="citation" data-cites="sql-on-fhir">(<a href="#ref-sql-on-fhir" role="doc-biblioref"><span>“<span>SQL</span> on <span>FHIR</span> speciification v0.0.1-pre,”</span> 2024</a>)</span>.</li>
<li><strong>Exploration:</strong> use on-demand, read-only analytical processing engines to provide a unified querying interface to access the heterogeneously structured data using new dataprocessing technologies such as DuckDB, polars etc. Should support SQL-on-FHIR Runners, such as Pathling, to generate the standardized views on demand.</li>
</ul>
<p>Strictly speaking, data consumer services are not part of the lakehouse solution design. In practice, these services are implemented using a combination of business intelligence (BI) reporting tools, and interactive development environment (IDE) to perform SQL queries and/or an interactive notebook computing environment <span class="citation" data-cites="granger2021jupyter">(<a href="#ref-granger2021jupyter" role="doc-biblioref">Granger and Perez, 2021</a>)</span>. In the discussion we will address the compatibility of this design to support federated learning and/or secure multiparty computation network.</p>
<p>In the following we describe how the high-level solution design has been implemented in Momcare. The first iteration describes Momcare Tanzania, the second Momcare Kenya. The demonstrators were also developed in that order. In the narrative of these demonstrators, we highlight key learnings and insights.</p>
</section>
<section id="momcare-demonstrators" class="level3">
<h3 class="anchored" data-anchor-id="momcare-demonstrators">Momcare demonstrators</h3>
<p>MomCare was launched in Kenya <span class="citation" data-cites="huisman2022digital sanctis2022maintaining">(<a href="#ref-huisman2022digital" role="doc-biblioref">Huisman et al., 2022</a>; <a href="#ref-sanctis2022maintaining" role="doc-biblioref">Sanctis et al., 2022</a>)</span> and Tanzania <span class="citation" data-cites="shija2021access mrema2021application">(<a href="#ref-mrema2021application" role="doc-biblioref">Mrema, 2021</a>; <a href="#ref-shija2021access" role="doc-biblioref">Shija et al., 2021</a>)</span> in 2017 and 2019 respectively, with the objective to improve health outcomes for maternal and antenatal care. MomCare distinguishes two user groups: mothers are supported during their pregnancy through reminders and surveys, using SMS as the digital mode of engagement. Health workers are equipped with an Android-based application, in which visits, care activities and clinical observations are recorded. Reimbursements of the maternal clinic are based on the data captured with SMS and the app, thereby creating a conditional payment scheme, where providers are partially reimbursed up-front for a fixed bundle of activities, supplemented by bonus payments based on a predefined set of care activities.</p>
<p>In its original form, the MomCare programme used closed digital platforms. In Kenya, M-TIBA is the primary digital platform, on top of which a relatively lightweight custom app has been built as the engagement layer for the health workers <span class="citation" data-cites="huisman2022digital">(<a href="#ref-huisman2022digital" role="doc-biblioref">Huisman et al., 2022</a>)</span>. M-TIBA provides data access through its data warehouse platform for the MomCare programme, however, this is not a standardized, general purpose API. In the case of Tanzania, a stand-alone custom app is used which does not provide an interface of any kind for interacting with the platform <span class="citation" data-cites="mrema2021application">(<a href="#ref-mrema2021application" role="doc-biblioref">Mrema, 2021</a>)</span>. Given these constraints, the first iteration of the MomCare programme used a custom-built data warehouse environment as its main data platform, on which data extractions, transformations and analysis are performed to generate the operational reports. Feedback reports for the health workers, in the form of operational dashboards, are made accessible through the app. Similar reports are provided to the back-office for the periodic reimbursement to the clinics.</p>
<p>Clearly, a more open and scaleable platform was required if MomCare was to be implemented in more regions. This need led to a redesign of the underlying technical infrastructure of the MomCare project. The objectives of this work were in fact to demonstrate a solution design that could support the first three types of data sharing. First, to investigate the viability of using FHIR for bulk data sharing, MomCare Tanzania was used a testbed to assess the complexity and effort required to implement the facade pattern to integrate the legacy system into the FHIR data standard. Using the longitudinal dataset from approximately 28 thousand patient records, FHIR transformations script were developed and deployed using the mediator function of the IOL. The data was transformed into 10 FHIR v4 resources and the conceptual data model of the existing MomCare app could readily be transformed into the FHIR standard using SQL and validated with a Python library <span class="citation" data-cites="islam2023fhir">(<a href="#ref-islam2023fhir" role="doc-biblioref">Islam, 2023</a>)</span>. The largest challenge during the transformation process pertained to the absence of unique business identifiers for patients and healthcare organizations. For patients, either the mobile phone number or the healthcare insurance number was taken, depending on availability. A combination of name, address and latitude/longitude coordinates were used to uniquely identify organizations and locations, as Tanzania does not have a system in place for this purpose.</p>
<p>The second objective was to reproduce existing analytic reports, using the bulk FHIR data format as input. Here, the focus was to standardize the logic required for producing metrics and reports. The transformed and validated data is uploaded into the FHIR server on a daily basis using an automated cloud function. Analysis of bulk data was done by directly reading the standard newline delimited JSON into the Python pandas data analysis library. Cross checking the output with queries on the original data confirmed that the whole data pipeline produced consistent results. For example, the report of the antenatal coverage metric (number of pregnancies with four or more visits) could be reproduced per patient journey and aggregated (per year, per organization etc.) as required for the MomCare reports.</p>
<p>The third objective was to run a technical feasibility test for federated analytics. Using the MPC platform of Roseman Labs, we managed to do aggregations in the blind … TO DO: explain that we managed to reproduce the reports we generated in the clear, but then in the blind. Note, however, that in the remainder we will focus on first two types of data sharing.</p>
<p>TO DO: explain logic of patient-timeline table. Write standard transformation to go from FHIR resources to this standard table. On top of that the actual metrics and reporting. Explain serverless: we wanted to get rid of resource-heavy data visualization tools. This led to the idea of serverless: using duckdb-wasm and pipelines of cloud functions.</p>
<section id="momcare-tanzania" class="level4">
<h4 class="anchored" data-anchor-id="momcare-tanzania">Momcare Tanzania</h4>
<div id="fig-momcare-tanzania" 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-momcare-tanzania-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Figure 2: Overview of Momcare Tanzania demonstrator.
</figcaption>
<div aria-describedby="fig-momcare-tanzania-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="./images/openhie-momcare-tz.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p>MomCare Tanzania was operational in Hanang district, which comprises a population of around 275 thousand spread over an area of 3.6 thousand square kilometers. In Hanang, all 33 public and faith-based maternal clinics currently participated in the MomCare programme. <a href="#fig-momcare-tanzania" class="quarto-xref">Figure 2</a> shows an overview of the components that were demonstrated in Momcare Tanzania.</p>
<section id="implementing-fhir-legacy-mediators" class="level5">
<h5 class="anchored" data-anchor-id="implementing-fhir-legacy-mediators">Implementing FHIR legacy mediators</h5>
<p>One of the practical objectives of the Momcare demonstrator was to assess the complexity and effort required to implement the data transformation scripts, and reproduce the existing analytic reports. The data was transformed into 10 FHIR v4 resources as listed in <a href="#tbl-data-tanzania" class="quarto-xref">Table 2</a> with the number of records per resource type. The conceptual data model of the existing MomCare app could readily be transformed into the FHIR standard using SQL and validated with a the fhir.resources Python library [TO DO: add reference].</p>
<p>The largest challenge during the transformation process pertained to the absence of unique business identifiers for patients and healthcare organizations. For patients, either the mobile phone number or the healthcare insurance number was taken, depending on availability. A combination of name, address and latitude/longitude coordinates were used to uniquely identify organizations and locations, as Tanzania does not have a system in place for this purpose.</p>
<p>The transformed and validated data is uploaded into the FHIR server on a daily basis using an automated cloud function. Analysis of bulk data was done by directly reading the standard newline delimited JSON into the Python pandas data analysis library. Cross checking the output with queries on the original data confirmed that the whole data pipeline produced consistent results. For example, the report of the antenatal coverage metric (number of pregnancies with four or more visits) could be reproduced per patient journey and aggregated (per year, per organization etc.) as required for the MomCare reports.</p>
<div id="tbl-data-tanzania" class="striped hover responsive quarto-float anchored">
<figure class="quarto-float quarto-float-tbl figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-tbl" id="tbl-data-tanzania-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Table 2: FHIR Resources from Momcare Tanzania.
</figcaption>
<div aria-describedby="tbl-data-tanzania-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<div class="table-responsive">
<table class="table-striped table-hover table">
<thead>
<tr class="header">
<th style="text-align: left;">FHIR v4 Resource</th>
<th style="text-align: left;">Number of records</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Patient</td>
<td style="text-align: left;">28,161</td>
</tr>
<tr class="even">
<td style="text-align: left;">Observation</td>
<td style="text-align: left;">28,587</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Episode of Care</td>
<td style="text-align: left;">20,571</td>
</tr>
<tr class="even">
<td style="text-align: left;">Organization</td>
<td style="text-align: left;">70</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Location</td>
<td style="text-align: left;">70</td>
</tr>
<tr class="even">
<td style="text-align: left;">Encounters</td>
<td style="text-align: left;">174,998</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Diagnoses</td>
<td style="text-align: left;">157,162</td>
</tr>
<tr class="even">
<td style="text-align: left;">Procedures</td>
<td style="text-align: left;">1,098,129</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Questionnaire</td>
<td style="text-align: left;">4</td>
</tr>
<tr class="even">
<td style="text-align: left;">Questionnaire Response</td>
<td style="text-align: left;">xxx</td>
</tr>
</tbody>
</table>
</div>
</div>
</figure>
</div>
</section>
<section id="standardizing-reporting-through-a-patient-timeline-table" class="level5">
<h5 class="anchored" data-anchor-id="standardizing-reporting-through-a-patient-timeline-table">Standardizing reporting through a patient timeline table</h5>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<figcaption>Data processing pipeline to standardize reporting for Momcare.</figcaption>
<p><img src="./images/standardized-reporting.png" class="img-fluid figure-img"></p>
</figure>
</div>
</section>
<section id="generating-different-reports-from-the-same-workflow" class="level5">
<h5 class="anchored" data-anchor-id="generating-different-reports-from-the-same-workflow">Generating different reports from the same workflow</h5>
</section>
</section>
<section id="momcare-kenya" class="level4">
<h4 class="anchored" data-anchor-id="momcare-kenya">Momcare Kenya</h4>
<section id="using-sql-on-fhir-v2-as-an-standardized-tabular-view-on-nested-fhir-data" class="level5">
<h5 class="anchored" data-anchor-id="using-sql-on-fhir-v2-as-an-standardized-tabular-view-on-nested-fhir-data">Using SQL-on-FHIR v2 as an standardized tabular view on nested FHIR data</h5>
<ul>
<li>At the time Momcare Tanzania demonstrator was build, SQL-on-FHIR v2 specification was still non-existant</li>
<li>We now have a working version for trial use, hence we migrated the code base from native SQL (DuckDB) to SQL on FHIR. This reduced the complexity of the code significantly, going from xx lines of code SQL to yy lines of code in the SQL-on-FHIR specification for the patient timeline table</li>
</ul>
<p>The premise of separating the user interface from the execution engine is directly related to the key objective of the SQL-on-FHIR project (<a href="https://build.fhir.org/ig/FHIR/sql-on-fhir-v2/">https://build.fhir.org/ig/FHIR/sql-on-fhir-v2/</a>), namely to make large-scale analysis of FHIR data accessible to a larger audience, portable between systems and to make FHIR data work well with the best available analytic tools, regardless of the technology stack. However, to use FHIR effectively analysts require a thorough understanding of the specification as FHIR is represented as a graph of resources, with detailed semantics defined for references between resources, data types, terminology, extensions, and many other aspects of the specification. Most analytic and machine learning use cases require the preparation of FHIR data using transformations and tabular projections from its original form. The task of authoring these transformations and projections is not trivial and there is currently no standard mechanisms to support reuse.</p>
<p>The solution of the SQL-on-FHIR project is to provide a specification for defining tabular, use case-specific views of FHIR data. The view definition and the execution of the view are separated, in such a way that the definition is portable across systems while the execution engine (called runners) are system-specific tools or libraries that apply view definitions to the underlying data layer, optionally making use of annotations to optimize performance.</p>
</section>
</section>
</section>
<section id="evaluation-of-momcare-demonstrators" class="level3">
<h3 class="anchored" data-anchor-id="evaluation-of-momcare-demonstrators">Evaluation of Momcare demonstrators</h3>
<p>We now reflect on the key learnings from the two Momcare demonstrators. We discuss each zone separately</p>
<section id="ingestion" class="level4">
<h4 class="anchored" data-anchor-id="ingestion">Ingestion</h4>
<ul>
<li>Default workflow is extraction of data from SHR using Bulk FHIR API. Data contains metadata (incl. FHIR versions) and fully qualified semantics, for example, coding systems. Despite this, metadata extraction and metadata modeling is still required to meet the FAIR requirements. Issues that need to be solved by these services:</li>
<li>To prepare for future updates of FHIR versions</li>
<li>Implement late-binding principle of having increasingly more specific FHIR profiles as bulk FHIR data propagates through lakehouse</li>
<li>FHIR vs. FAIR
<ul>
<li>How does FHIR relate to approaches taken by the FAIR community, which tend to take more an approach of using knowledge graphs. For example, VODAN Africa <span class="citation" data-cites="gebreslassie2023fhir4fair purnamajati2022data">(<a href="#ref-gebreslassie2023fhir4fair" role="doc-biblioref">Gebreslassie et al., 2023</a>; <a href="#ref-purnamajati2022data" role="doc-biblioref">Purnama Jati et al., 2022</a>)</span>.</li>
<li>FAIR principles vs FHIR graph: is FHIR a FAIR Data Object</li>
</ul></li>
<li>Since we use FHIR, we don’t need a semantic layer because that is already provided</li>
<li>We do need different semantic layer, namely with metrics. Explain different types of semantics.
<ul>
<li>The metrics layer same function as CQL. Discuss CQL vs generic metrics layer.</li>
</ul></li>
</ul>
</section>
<section id="storage" class="level4">
<h4 class="anchored" data-anchor-id="storage">Storage</h4>
<ul>
<li>File-based:
<ul>
<li>from ndjson to parquet</li>
<li>possibly used delta lake for time versioning</li>
<li>separation of storage from compute not only for benefits of lower TCO, but also be ready for federated learning and MPC in future</li>
</ul></li>
</ul>
</section>
<section id="maintenance" class="level4">
<h4 class="anchored" data-anchor-id="maintenance">Maintenance</h4>
<ul>
<li>SQL-on-FHIR Views provide new standard to support mADX aggregate reporting !! We need to stress this, because this is an existing OpenHIE workflow</li>
<li>Maintenance-related functions remain the same</li>
<li>NB: orchestration falls under data provenance</li>
<li>NB: make comparison with HMIS component
<ul>
<li>workflow requirements: Report aggregate data (link): receiver is HMIS, mADX; this is not analytics!</li>
<li>Functional requirements: https://guides.ohie.org/arch-spec/openhie-component-specifications-1/openhie-health-management-information-system-hmis</li>
<li>Requirements are similar, but implementation differs: Datamodel is non-FHIR, focused on DataValue, which conceptually equates to FHIR Measure</li>
</ul></li>
</ul>
<p>Based on these experiments, we arrived at the following design for the data & analytics services</p>
<ul>
<li>Use ‘serverless’ file-based storage: bulk copy of data as-is in parquet
<ul>
<li>Tension: how to manage change data capture</li>
<li>Tension: how to manage access rights</li>
</ul></li>
<li>Use SQL-on-FHIR-v2 to create tabular views.
<ul>
<li>Example: patient timeline</li>
<li>TO DO: rewrite patient timeline queries with SQL-on-FHIR-v2 and run it with Pathling</li>
</ul></li>
<li>Use semantic modeling layer to define metrics
<ul>
<li>There are many options: dbt, cube.dev</li>
<li>Fulfills same function as ADX/mADX IHE profile in OpenHIE specification</li>
<li>Tension: going from patient-timeline to reported metrics still isn’t standardized. This is where Ibis/Substrait comes in. Substrait as IR for cross-language serialization for relational algebra. Can be executed on different backends. Write once, run on different engines.</li>
</ul></li>
<li>Distribute and publish reports on resource-constrained devices
<ul>
<li>duckdb</li>
<li>sveltekit</li>
</ul></li>
</ul>
</section>
</section>
</section>
<section id="discussion" class="level2">
<h2 class="anchored" data-anchor-id="discussion">Discussion</h2>
<section id="jembi-openhim-platform" class="level3">
<h3 class="anchored" data-anchor-id="jembi-openhim-platform">Jembi OpenHIM platform</h3>
<p>First, we compare the extended OpenHIE architecture described above to the OpenHIM Platform. The Open Health Information Mediator (OpenHIM, <a href="OpenHIMhttp://openhim.org/">http://openhim.org/</a>)) component is the reference implementation of the Interoperability Layer (IOL) as defined in the OpenHIE specification. The most current version (8.4.2 at the time of writing) provides all the core functions including central point of access for the services of the HIE; routing functions; central logging for auditing and debugging purposes; and orchestration/mediation mechanisms to co-ordinate requests. By extension, the OpenHIM Platform (<a href="https://jembi.gitbook.io/openhim-platform">https://jembi.gitbook.io/openhim-platform</a>) is a reference implementation of a set of Instant OpenHIE configurations, refered to as ‘recipes’ in the documentation. One such recipe enables instant deployment of “a central data repository with a data warehouse” that provides “A FHIR-based Shared Health record linked to a Master Patient Index (MPI) for linking and mathing patient demographics and a default reporting pipeline to transform and visualise FHIR data” (<a href="https://jembi.gitbook.io/openhim-platform/recipes/central-data-repository-with-data-warehousing">https://jembi.gitbook.io/openhim-platform/recipes/central-data-repository-with-data-warehousing</a>).</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 3: Overview of the default data stack of the OpenHIM Platform. The default stack (top, red) consists of Kafka, Clickhouse and Superset. An alternative solution based on the ELK stack is also supported (bottom, orange), consisting of Elasticsearch, Logstash and Kibana.
</figcaption>
<div aria-describedby="fig-openhim-platform-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<img src="images/openhim-platform.png" class="img-fluid figure-img">
</div>
</figure>
</div>
<p><a href="#fig-openhim-platform" class="quarto-xref">Figure 3</a> shows a schematic overview of two data stacks that are supported in the OpenHIM platform. The Shared Health Record (SHR, implemented with HAPI FHIR server) and the Client Registry (CR, implemented with JeMPI server) are the sources that store clinical FHIR data and patient demographic data, respectively. The default data stack is based on streaming ingestion using Kafka into a Clickhouse database. As part of the ingestion, incoming FHIR bundles that contain multiple FHIR resources are unbundled in separate topics using a generic Kafka utility component. Subsequently, each FHIR resource topic is flatted with Kafka mappers that use FHIRPath. Superset is used as the tool for consuming the data to create dashboard visualizations.</p>
<p>The OpenHIM platform also support data and analytics based on the ELK stack, where data is ingested in bulk using Logstash, stored in Elasticsearch and made available for consumption in Kibana. Also here, the incoming FHIR bundles are unbundled in Logstash into separate FHIR resources. However, given that Elasticsearch is a document-based search engine, the FHIR resources are stored as-is with no flattening. Exploring and analysing the data requires writing queries in Elasticsearch Query Language (ES|QL), either through the query interface of Elasticsearch or using Kibana.</p>
<p>Evaluating these two data stacks, we see the following:</p>
<ul>
<li>Pattern of flattening FHIR resources with FHIRPath expressions is very close to the idea of SQL-on-FHIR. Although it doesn’t adhere to this new standard in the strict sense, the philosophy of generating tabular views is the same</li>
<li>When using the ELK stack, flattening is done at the end. Implementations of FHIRPath support Elasticsearch as an execution engine, also here</li>
<li>Main limitations: both Clickhouse en Elasticsearch don’t follow decomposition of storage, compute and UI. Therefore, downward scaleability is limited.</li>
</ul>
</section>
<section id="ona-opensrp-2" class="level3">
<h3 class="anchored" data-anchor-id="ona-opensrp-2">ONA OpenSRP 2</h3>
<p>Continuing our evaluation of the extended OpenHIE architecture, we can see a different flavor in the implementation of the OpenSRP2 stack, which is a global public good that has been deployed in XX countries worldwide. Ona, a social enterprise based in Nairobi, is the lead developer OpenSRP2, which at the time of writing has been implemented in the field in three countries (Uganda, Liberia, and Madagascar) in collaboration with local Ministries of Health and with international donors such as UNICEF, supporting a variety of different workflows including antenatal care (ANC), postnatal Care (PNC), immunization, and last-mile logistics.</p>
<p>Based on learnings from previous versions of OpenSRP, the data & analytics stack implemented in OpenSRP2 was designed to support a national-scale implementation of an end-to-end FHIR-based workflow, that start with data collection through an app build on the Open Health Stack Android SDK all the way down to a FHIR-based data & analytics platform. The requirements for data & analytics are shown in <a href="#tbl-ona-requirements" class="quarto-xref">Table 3</a>.</p>
<div id="tbl-ona-requirements" class="striped hover responsive quarto-float anchored">
<figure class="quarto-float quarto-float-tbl figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-tbl" id="tbl-ona-requirements-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Table 3: Requirements and rationale for open health data platform developed and used by ONA, based on OpenSRP 2 (<a href="https://opensrp.io/">https://opensrp.io/</a>).
</figcaption>
<div aria-describedby="tbl-ona-requirements-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<div class="table-responsive">
<table class="table-striped table-hover table">
<colgroup>
<col style="width: 28%">
<col style="width: 71%">
</colgroup>
<thead>
<tr class="header">
<th style="text-align: left;">Requirement</th>
<th style="text-align: left;">Rationale</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Ingest data from multiple sources, both FHIR and non-FHIR based.</td>
<td style="text-align: left;">While most health record data can be collected and aggregated in FHIR, Ministries of Health rely on other data sources to govern their operations. For example, operationalizing an immunization campaign usually includes tracking against specific targets for locations to be visited on specific days and number of children to immunize per day. Such targets are often stored in spreadsheets or other applications where the data is not FHIR.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Ingest data in batches.</td>
<td style="text-align: left;">Most data ingestion can happen in batches, since Ona’s applications are deployed in hard to reach areas where connectivity is an issue. Data ingestion closer to real-time can be relevant for disaster-response and other time-sensitive applications, but this is not a priority.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Support national-scale data volumes.</td>
<td style="text-align: left;">A data store that can grow from dozens to thousands of devices and where data can be aggregated up to the national level, matching the scale of implementation of data collection applications in the field.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Pre-compute complex business metrics.</td>
<td style="text-align: left;">Reporting on health systems requires pre-computing complex metrics and often performing cohort analyses to map trends in service provision. For example, understanding quality of care for children requires computing metrics such as the percentage of children fully immunized on schedule (i.e. children 6-59 months that have received the set of vaccines required by the Ministry of Health, and have received each of those vaccines within the expected age-window). For Business Intelligence applications, calculating such a vital metric cannot be performed at run time, to avoid long and expensive queries.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Outbound integrations.</td>
<td style="text-align: left;">While aggregated data and reports should be accessible by other applications such as BI platforms via pulls, there should be an easy integration framework to push data to other applications used by the Ministry of Health for other purposes, such as DHIS2 for health systems management or RapidPro for communications with program beneficiaries.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Open source and easily deployable in-country.</td>
<td style="text-align: left;">Given the extremely sensitive nature of health data, it is paramount for governments to have the flexibility to deploy the stack in various different environments, both on premise and in private clouds.</td>
</tr>
</tbody>
</table>
</div>
</div>
</figure>
</div>
<p>The architecture Learning from experience in the field and internal research and development, Ona has developed preferences for a specific data stack responding to the aforementioned requirements.</p>
<p>[[graphic]]</p>
<p>Core toolings in the stack include:</p>
<ul>
<li>Data ingestion with Airbyte. Ona uses Airbyte as the primary data ingestion tool, leveraging the wide array of connectors that come standard with the application as well as a dedicated suite of connectors developed internally by Ona, including HAPI FHIR, RapidPro, Ona Data, Kobo Toolbox and others.<br>
</li>
<li>Data storage with Clickhouse. While different health projects have varying requirements, Ona has found success in using Clickhouse as the main analytics data store in its most recent implementations. Clickhouse supports the scale required for analytics at a national level, as well as the speed that enables cross-application integrations and more real-time analytics. For example, in Madagascar Ona uses its reporting suite to identify facilities with stock in need of maintenance and can trigger the scheduling of a maintenance visit ad hoc.</li>
<li>Data transformation with dbt. Following global best practice, Ona leverages dbt to segregate the data warehouse in different levels (staging, marts, metrics), as well as pre-computing complex indicators for ease of reporting and for transmissions into other systems. For example, in Liberia Ona implements OpenSRP at community health worker level, but can aggregate immunization data at facility level in the data warehouse and then push quarterly summary metrics to DHIS2.</li>
<li>No recommendation on reporting / BI tooling. Ona recognizes that business users have their own strong preferences for BI tooling, and some already have licenses for specific software, so the architecture is flexible to provide easy connections to different BI tools.</li>
</ul>
<p>Use of generic best-of-breed tooling. Ona focused on utilizing Open HIE tools that are widely adopted outside of the global health and development sectors. This approach aims to provide assurance on two main fronts, the ability to handle performance at scale and the long term dependability of the tools, rather than relying on smaller projects with uncertain long term funding or unproven implementations. Columnar data warehouse for analytics. The scale of Ona’s project requires the implementation of a dedicated database for analytics. While original data can still be stored as parquet or other file system, being able to ingest it into a relational data store allows to create well defined indicators. Using clickhouse as a tool helps and combine the need accuracy with the speed of reporting as new data is ingested.<br>
Strong emphasis on SQL. While Ona has tested and experimented with FHIR-specific tooling, such as the definition of data projections using sql-on-fhir, Ona found that relying on sql for coding business logic remained the faster and most scalable approach.</p>
<p>In summary, for Ona building analytics with FHIR data looks similar to building analytics with any other type of data. While FHIR provides a clear and standard data model, managing information for most health systems requires custom integration of data between different sources, as well as computing indicators using business logic specific to the needs of the local users. Building upon well established best-of-breed tools allows Ona to implement FHIR applications at scale and provide trusted analytics on top.</p>
</section>
<section id="assessment-of-design-principles" class="level3">
<h3 class="anchored" data-anchor-id="assessment-of-design-principles">Assessment of design principles</h3>
<p>Given the solution design, and the comparison with the two widely used open source implementations that is backed by an active community, we discuss the pros and cons from different perspectives that we believe are essential design principles to realise solidarity-based OHDSs, namely [TO DO: this is just first shot at formulating our design principles; needs refinement]:</p>
<ul>
<li>inclusive-by-design, based on the notions of datasolidarity and maximising autonomy of all future participants in the ecosystem;</li>
<li>scaleable-by-design, particularly focusing on downward scaleability to support a decentralized platform topology to allows for bottom-up deployment scenarios (from local care networks –> county-level networks –> national networks) instead of top-down national roll-out;</li>
<li>open-by-design, whereby a balance is found to resort to minimal standards and allow for a large diversity of partners and technologies to be used;</li>
</ul>
<section id="inclusive-by-design-datasolidarity-fairness-and-autonomy" class="level4">
<h4 class="anchored" data-anchor-id="inclusive-by-design-datasolidarity-fairness-and-autonomy">Inclusive-by-design: datasolidarity, FAIRness and autonomy</h4>
<ul>
<li>which can be framed within the context of ongoing efforts towards Findable, Accessible, Interoperable and Reusable (FAIR) sharing of health data <span class="citation" data-cites="guillot2023fair">(<a href="#ref-guillot2023fair" role="doc-biblioref">Guillot et al., 2023</a>)</span>.</li>
<li>equitable data sharing requires more than just FAIRification <span class="citation" data-cites="evertsz2023what">(<a href="#ref-evertsz2023what" role="doc-biblioref">Evertsz et al., 2023</a>)</span></li>
</ul>
</section>
<section id="scaleable-by-design" class="level4">
<h4 class="anchored" data-anchor-id="scaleable-by-design">Scaleable-by-design</h4>
<p>Today, many components of the OpenHIE specification are now available as a digital public goods. Typically, these open source components are intended to support deployments in small countries (population up to 10 million) or large NGOs out of the box, and should provide a stepping stone for customized deployments in medium-sized countries (population around 40 million).<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a> To further ease the development, configuration and deployment of health information exchanges, the concept of ‘Instant OpenHIE’ has been championed to (i) allow implementers to engage with a preconfigured health information exchange solution and running tools (based on the architecture) and test their applicability and functionality with a real health context problem; and (ii) have a packaged reference version of the OpenHIE architecture that is comprised of a set of reference technologies and other appropriate tools that form the building blocks of the health information exchange that can be configured and extended to support particular use cases <span class="citation" data-cites="InstantOpenHIEv2">(<a href="#ref-InstantOpenHIEv2" role="doc-biblioref"><span>“Instant <span>OpenHIE</span> v2.2.0,”</span> 2024</a>)</span>. Besides the core functional components of the OpenHIE architecture, the Instant OpenHIE toolkit allows packaging and integration of generic components such as Identity and Access Managment (IAM) and a reverse proxy gateway. In the following, we will evaluatie three of such configurations, with the aim to conceptualize and evaluate the proposed Data and Analytics Services domain of of the OpenHIE architecture.</p>
<p>We also posit that a decentralized platform is more conducive to realize a solidarity-based approach to health data sharing that i) gives people a greater control over their data as active decision makers; ii) ensures that the value of data is harnessed for public good; and iii) moves society towards equity and justice by counteracting dynamics of data extraction <span class="citation" data-cites="prainsack2022data">(<a href="#ref-prainsack2022data" role="doc-biblioref">Prainsack et al., 2022</a>)</span>. With this approach, we purposefully challenge the dominant paradigm of designing and implementing centralized platforms to support the digital transformation of healthcare in LMICs <span class="citation" data-cites="ogundaini2022systematic">(<a href="#ref-ogundaini2022systematic" role="doc-biblioref">Ogundaini and Achieng, 2022</a>)</span> with the aim to make digital platforms work <em>for</em> development <span class="citation" data-cites="hermes2020digital">(<a href="#ref-hermes2020digital" role="doc-biblioref">Hermes et al., 2020</a>)</span>.</p>
<p>[TO DO: elaborate on how we see this solution design can be implemented from the bottom-up, typically in a primary care network serving a population of around 80,000 people with level 3 facilities that have limited resources]</p>
<div id="tbl-kenya-facilities" class="quarto-float anchored">
<figure class="quarto-float quarto-float-tbl figure">
<figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-tbl" id="tbl-kenya-facilities-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
Table 4: Number of healthcare facilities in Kenya. Source: Kenya Health Facility Census, Ministry of Health, September 2023.
</figcaption>
<div aria-describedby="tbl-kenya-facilities-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">
<table class="table">
<colgroup>
<col style="width: 13%">
<col style="width: 61%">
<col style="width: 25%">
</colgroup>
<thead>
<tr class="header">
<th style="text-align: center;">Level</th>
<th>Description</th>
<th style="text-align: right;">Number of facilities</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">2</td>
<td>Dispensaries and private clincs, typically located in a school, industrial plant or other organization that dispenses medication and sometimes basic medical and dental treatment</td>
<td style="text-align: right;">8,806</td>
</tr>
<tr class="even">
<td style="text-align: center;">3</td>
<td>Health centres, medium-sized units which cater for a population of about 80,000 people</td>
<td style="text-align: right;">2,559</td>
</tr>
<tr class="odd">
<td style="text-align: center;">4</td>
<td>Sub-county hospital, similar to health centres with additional facilities for more complex procedures</td>
<td style="text-align: right;">971</td>
</tr>
<tr class="even">
<td style="text-align: center;">5</td>
<td>County referral hospital, regional centres which provide specialised care</td>
<td style="text-align: right;">34</td>
</tr>
<tr class="odd">
<td style="text-align: center;">6</td>
<td>National referral hospital</td>
<td style="text-align: right;">5</td>
</tr>
</tbody>
</table>
</div>
</figure>
</div>
</section>
<section id="open-by-design-mitigating-risk-and-rebalancing-asymmetries" class="level4">
<h4 class="anchored" data-anchor-id="open-by-design-mitigating-risk-and-rebalancing-asymmetries">Open-by-design: mitigating risk and rebalancing asymmetries</h4>
<p>The shift in perspective from digital platforms to data platforms coincides with the paradox of open <span class="citation" data-cites="keller2021paradox">(<a href="#ref-keller2021paradox" role="doc-biblioref">Keller and Tarkowski, 2021</a>)</span>. Originally, openness of digital platforms focused on open source and open standards (as shown above for OpenHIE) which by has been superseded by “… conflicts about privacy, economic value extraction, the emergence of artificial intelligence, and the destabilizing effects of dominant platforms on (democratic) societies. Instead of access to information, the control of personal data has emerged in the age of platforms as the critical contention.” <span class="citation" data-cites="keller2021paradox">(<a href="#ref-keller2021paradox" role="doc-biblioref">Keller and Tarkowski, 2021</a>)</span>. These conflicts are particularly salient in the healthcare domain, where people are generally willing to share their health data to receive the best care (primary use, which is aligned with the concept of digital platforms), while the attitude towards secondary use of health data (conceptually aligned with a data platform) varies greatly depending on the type and context <span class="citation" data-cites="cascini2024health">(<a href="#ref-cascini2024health" role="doc-biblioref">Cascini et al., 2024</a>)</span>. The shift in perspective from digital platforms supporting primary data sharing toward data platforms supporting secondary data sharing is one of the key issues surrounding the polemic of data spaces <span class="citation" data-cites="otto2022designing">(<a href="#ref-otto2022designing" role="doc-biblioref">Otto et al., 2022</a>)</span> and data solidarity <span class="citation" data-cites="kickbusch2021lancet prainsack2022data prainsack2023beyond purtova2023data">(<a href="#ref-kickbusch2021lancet" role="doc-biblioref">Kickbusch et al., 2021</a>; <a href="#ref-prainsack2022data" role="doc-biblioref">Prainsack et al., 2022</a>; <a href="#ref-prainsack2023beyond" role="doc-biblioref">Prainsack and El-Sayed, 2023</a>; <a href="#ref-purtova2023data" role="doc-biblioref">Purtova and van Maanen, 2023</a>)</span>.</p>
<ul>
<li>Risk of openness: What are the novel (negative) implications of opening up data platforms? How can reflexivity in design help providers to resolve the negative implications of openness?</li>
<li>Answers/insights to above:
<ul>
<li>Openness of standardized view on FHIR data and cross-language serialization of relational algebra makes it possible to fully standardize the workflow from start to finish</li>
<li>Platform-to-platform: MPC</li>
<li>Risk of openness: difficult to answer …</li>
</ul></li>
<li>Paradox of open in disucssion: we started with hypotheses that a decentralized approach will lead to distribution of power, hence … But is this really the case? Will open source not backfire and strengthen their position?</li>
</ul>
</section>
</section>
<section id="limitation-and-future-work" class="level3">
<h3 class="anchored" data-anchor-id="limitation-and-future-work">Limitation and future work</h3>
<ul>
<li>Access control is still a pain-point, can we move to Attribute-based access control?
<ul>
<li>TO DO: if you have generated flattened SQL tables, how are you going to manage security?</li>
<li>Cerbos, attribute based on lineage or anonymized tables</li>
<li>Catalogs solve this: Tabular.io, Google BigLake. What is open source option?</li>
</ul></li>
<li>Federated learning and multiparty computation
<ul>
<li>Lakehouse serves as datastations</li>
<li>Explain first results Roseman Labs</li>
</ul></li>
<li>… [more future work items here]</li>
</ul>
</section>
</section>
<section id="conclusion" class="level2">
<h2 class="anchored" data-anchor-id="conclusion">Conclusion</h2>
</section>
<section id="acknowledgements" class="level2">
<h2 class="anchored" data-anchor-id="acknowledgements">Acknowledgements</h2>
</section>
<section id="conflicts-of-interest" class="level2">
<h2 class="anchored" data-anchor-id="conflicts-of-interest">Conflicts of interest</h2>
<p>DK received funding from PharmAccess to conduct this work as a contractor. SW/IntelliSOFT received funding from PharmAccess as an implementation partner in various projects. AP/ONA received funding from PharmAccess to develop an improved version of one of the components of the open source OpenSRP 2 framework.</p>
</section>
<section id="abbreviations" class="level2">
<h2 class="anchored" data-anchor-id="abbreviations">Abbreviations</h2>
<table class="table">
<tbody>
<tr class="odd">
<td style="text-align: left;">ACID</td>
<td style="text-align: left;">Atomicity, Consistency, Isolation, and Durability</td>
</tr>
<tr class="even">
<td style="text-align: left;">CLI</td>
<td style="text-align: left;">Command-line Interface</td>
</tr>
<tr class="odd">
<td style="text-align: left;">CR</td>
<td style="text-align: left;">Client Registry</td>
</tr>
<tr class="even">
<td style="text-align: left;">DHI</td>
<td style="text-align: left;">Digital Health Intervention</td>
</tr>
<tr class="odd">
<td style="text-align: left;">ELK</td>
<td style="text-align: left;">Elasticsearch, Logstach and Kibana stack</td>
</tr>
<tr class="even">
<td style="text-align: left;">ELT</td>
<td style="text-align: left;">Extract, Load and Transform</td>
</tr>
<tr class="odd">
<td style="text-align: left;">FAIR</td>
<td style="text-align: left;">Findable, Accessible, Interoperable and Reusable</td>
</tr>
<tr class="even">
<td style="text-align: left;">FHIR</td>
<td style="text-align: left;">Fast Healthcare Interoperability Resources</td>
</tr>
<tr class="odd">
<td style="text-align: left;">FL</td>
<td style="text-align: left;">Federated learning</td>
</tr>
<tr class="even">
<td style="text-align: left;">HIE</td>
<td style="text-align: left;">Health Information Exchange</td>
</tr>
<tr class="odd">
<td style="text-align: left;">LMIC</td>
<td style="text-align: left;">Low- and middle income countries</td>
</tr>
<tr class="even">
<td style="text-align: left;">MPC</td>
<td style="text-align: left;">Multiparty Computation</td>
</tr>
<tr class="odd">
<td style="text-align: left;">PET</td>
<td style="text-align: left;">Privacy-enhancing technologies</td>
</tr>
<tr class="even">
<td style="text-align: left;">OHDS</td>
<td style="text-align: left;">Open health data system</td>
</tr>
<tr class="odd">
<td style="text-align: left;">SHR</td>
<td style="text-align: left;">Shared Health Record</td>
</tr>
</tbody>
</table>
</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 hanging-indent" data-entry-spacing="0" role="list">
<div id="ref-armbrust2021lakehouse" class="csl-entry" role="listitem">
Armbrust, M., Ghodsi, A., Xin, R., Zaharia, M., 2021. Lakehouse: <span>A New Generation</span> of <span>Open Platforms</span> that <span>Unify Data Warehousing</span> and <span>Advanced Analytics</span>, in: 11th <span>Annual Conference</span> on <span>Innovative Data Systems Research</span> (<span>CIDR</span> ’21). p. 8.
</div>
<div id="ref-bartlett2021insights" class="csl-entry" role="listitem">
Bartlett, L., Avery, L., Ponnappan, P., Chelangat, J., Cheruiyot, J., Matthews, R., Rocheleau, M., Tikkanen, M., Allen, M., Amendola, P., Labrique, A., 2021. Insights into the design, development and implementation of a novel digital health tool for skilled birth attendants to support quality maternity care in <span>Kenya</span>. Family Medicine and Community Health 9, e000845. <a href="https://doi.org/10.1136/fmch-2020-000845">https://doi.org/10.1136/fmch-2020-000845</a>
</div>
<div id="ref-cascini2024health" class="csl-entry" role="listitem">
Cascini, F., Pantovic, A., Al-Ajlouni, Y.A., Puleo, V., De Maio, L., Ricciardi, W., 2024. Health data sharing attitudes towards primary and secondary use of data: A systematic review. eClinicalMedicine 71, 102551. <a href="https://doi.org/10.1016/j.eclinm.2024.102551">https://doi.org/10.1016/j.eclinm.2024.102551</a>
</div>
<div id="ref-dalhatu2023paper" class="csl-entry" role="listitem">
Dalhatu, I., Aniekwe, C., Bashorun, A., Abdulkadir, A., Dirlikov, E., Ohakanu, S., Adedokun, O., Oladipo, A., Jahun, I., Murie, L., Yoon, S., Abdu-Aguye, M.G., Sylvanus, A., Indyer, S., Abbas, I., Bello, M., Nalda, N., Alagi, M., Odafe, S., Adebajo, S., Ogorry, O., Akpu, M., Okoye, I., Kakanfo, K., Onovo, A.A., Ashefor, G., Nzelu, C., Ikpeazu, A., Aliyu, G., Ellerbrock, T., Boyd, M., Stafford, K.A., Swaminathan, M., 2023. 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>. Methods of Information in Medicine 62, 130–139. <a href="https://doi.org/10.1055/s-0043-1768711">https://doi.org/10.1055/s-0043-1768711</a>
</div>
<div id="ref-dereuver2022openness" class="csl-entry" role="listitem">
de Reuver, M., Ofe, H., Agahari, W., Abbas, A.E., Zuiderwijk, A., 2022. The openness of data platforms: A research agenda, in: Proceedings of the 1st <span>International Workshop</span> on <span>Data Economy</span>, <span>DE</span> ’22. Association for Computing Machinery, New York, NY, USA, pp. 34–41. <a href="https://doi.org/10.1145/3565011.3569056">https://doi.org/10.1145/3565011.3569056</a>
</div>
<div id="ref-dennis2019initiation" class="csl-entry" role="listitem">
Dennis, M.L., Benova, L., Abuya, T., Quartagno, M., Bellows, B., Campbell, O.M.R., 2019. Initiation and continuity of maternal healthcare: Examining the role of vouchers and user-fee removal on maternal health service use in <span>Kenya</span>. Health Policy and Planning 34, 120–131. <a href="https://doi.org/10.1093/heapol/czz004">https://doi.org/10.1093/heapol/czz004</a>
</div>
<div id="ref-dohmen2022implementing" class="csl-entry" role="listitem">
Dohmen, P., De Sanctis, T., Waiyaiya, E., Janssens, W., Rinke de Wit, T., Spieker, N., Van der Graaf, M., Van Raaij, E.M., 2022. Implementing value-based healthcare using a digital health exchange platform to improve pregnancy and childbirth outcomes in urban and rural <span>Kenya</span>. Frontiers in Public Health 10. <a href="https://doi.org/10.3389/fpubh.2022.1040094">https://doi.org/10.3389/fpubh.2022.1040094</a>
</div>
<div id="ref-evertsz2023what" class="csl-entry" role="listitem">
Evertsz, N., Bull, S., Pratt, B., 2023. What constitutes equitable data sharing in global health research? <span>A</span> scoping review of the literature on low-income and middle-income country stakeholders’ perspectives. BMJ Global Health 8, e010157. <a href="https://doi.org/10.1136/bmjgh-2022-010157">https://doi.org/10.1136/bmjgh-2022-010157</a>
</div>
<div id="ref-gebreslassie2023fhir4fair" class="csl-entry" role="listitem">
Gebreslassie, T.G., van Reisen, M., Amare, S.Y., Taye, G.T., Plug, R., 2023. <span>FHIR4FAIR</span>: <span>Leveraging FHIR</span> in health data <span>FAIRfication</span> process: <span>In</span> the case of <span>VODAN-A</span>. FAIR Connect 1, 49–54. <a href="https://doi.org/10.3233/FC-230504">https://doi.org/10.3233/FC-230504</a>
</div>
<div id="ref-granger2021jupyter" class="csl-entry" role="listitem">
Granger, B.E., Perez, F., 2021. Jupyter: <span>Thinking</span> and <span>Storytelling With Code</span> and <span>Data</span>. Computing in Science & Engineering 23, 7–14. <a href="https://doi.org/10.1109/MCSE.2021.3059263">https://doi.org/10.1109/MCSE.2021.3059263</a>
</div>
<div id="ref-guillot2023fair" class="csl-entry" role="listitem">
Guillot, P., Bøgsted, M., Vesteghem, C., 2023. <span>FAIR</span> sharing of health data: A systematic review of applicable solutions. Health and Technology 13, 869–882. <a href="https://doi.org/10.1007/s12553-023-00789-5">https://doi.org/10.1007/s12553-023-00789-5</a>
</div>
<div id="ref-hai2023data" class="csl-entry" role="listitem">
Hai, R., Koutras, C., Quix, C., Jarke, M., 2023. Data <span>Lakes</span>: <span>A Survey</span> of <span>Functions</span> and <span>Systems</span>. IEEE Transactions on Knowledge and Data Engineering 35, 12571–12590. <a href="https://doi.org/10.1109/TKDE.2023.3270101">https://doi.org/10.1109/TKDE.2023.3270101</a>
</div>
<div id="ref-harby2024data" class="csl-entry" role="listitem">
Harby, A.A., Zulkernine, F., 2024. Data <span>Lakehouse</span>: <span>A Survey</span> and <span>Experimental Study</span>. <a href="https://doi.org/10.2139/ssrn.4765588">https://doi.org/10.2139/ssrn.4765588</a>
</div>
<div id="ref-harby2022data" class="csl-entry" role="listitem">
Harby, A.A., Zulkernine, F., 2022. From <span>Data Warehouse</span> to <span>Lakehouse</span>: <span>A Comparative Review</span>, in: 2022 <span>IEEE International Conference</span> on <span>Big Data</span> (<span>Big Data</span>). IEEE, Osaka, Japan, pp. 389–395. <a href="https://doi.org/10.1109/BigData55660.2022.10020719">https://doi.org/10.1109/BigData55660.2022.10020719</a>
</div>
<div id="ref-hermes2020digital" class="csl-entry" role="listitem">
Hermes, S., Riasanow, T., Clemons, E.K., Böhm, M., Krcmar, H., 2020. The digital transformation of the healthcare industry: Exploring the rise of emerging platform ecosystems and their influence on the role of patients. Business Research 13, 1033–1069. <a href="https://doi.org/10.1007/s40685-020-00125-x">https://doi.org/10.1007/s40685-020-00125-x</a>
</div>
<div id="ref-huisman2022digital" class="csl-entry" role="listitem">
Huisman, L., van Duijn, S.M., Silva, N., van Doeveren, R., Michuki, J., Kuria, M., Otieno Okeyo, D., Okoth, I., Houben, N., Rinke de Wit, T.F., Rogo, K., 2022. A digital mobile health platform increasing efficiency and transparency towards universal health coverage in low- and middle-income countries. Digital Health 8, 20552076221092213. <a href="https://doi.org/10.1177/20552076221092213">https://doi.org/10.1177/20552076221092213</a>
</div>
<div id="ref-InstantOpenHIEv2" class="csl-entry" role="listitem">
Instant <span>OpenHIE</span> v2.2.0, 2024.
</div>
<div id="ref-islam2023fhir" class="csl-entry" role="listitem">
Islam, M.N., 2023. Fhir.resources: <span>FHIR Resources</span> as <span>Model Class</span>.
</div>
<div id="ref-izudi2023experiences" class="csl-entry" role="listitem">
Izudi, J., Owoko, H.O., Bagayoko, M., Kadengye, D., 2023. Experiences of mothers and health workers with <span>MomCare</span> and <span>SafeCare</span> bundles in <span>Kenya</span> and <span>Tanzania</span>: <span>A</span> qualitative evaluation. PloS One 18, e0294536. <a href="https://doi.org/10.1371/journal.pone.0294536">https://doi.org/10.1371/journal.pone.0294536</a>
</div>
<div id="ref-jain2023analyzing" class="csl-entry" role="listitem">
Jain, P., Kraft, P., Power, C., Das, T., Stoica, I., Zaharia, M., 2023. Analyzing and <span>Comparing Lakehouse Storage Systems</span>.
</div>
<div id="ref-jones2021landscape" class="csl-entry" role="listitem">
Jones, J., Gottlieb, D., Mandel, J.C., Ignatov, V., Ellis, A., Kubick, W., Mandl, K.D., 2021. A landscape survey of planned <span>SMART</span>/<span>HL7</span> bulk <span>FHIR</span> data access <span>API</span> implementations and tools. Journal of the American Medical Informatics Association 28, 1284–1287. <a href="https://doi.org/10.1093/jamia/ocab028">https://doi.org/10.1093/jamia/ocab028</a>
</div>
<div id="ref-jordan2022selecting" class="csl-entry" role="listitem">
Jordan, S., Fontaine, C., Hendricks-Sturrup, R., 2022. Selecting <span>Privacy-Enhancing Technologies</span> for <span>Managing Health Data Use</span>. Frontiers in Public Health 10, 814163. <a href="https://doi.org/10.3389/fpubh.2022.814163">https://doi.org/10.3389/fpubh.2022.814163</a>
</div>
<div id="ref-karamagi2022ehealth" class="csl-entry" role="listitem">
Karamagi, H.C., Muneene, D., Droti, B., Jepchumba, V., Okeibunor, J.C., Nabyonga, J., Asamani, J.A., Traore, M., Kipruto, H., 2022. <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. Journal of Global Health 12, 04090. <a href="https://doi.org/10.7189/jogh.12.04090">https://doi.org/10.7189/jogh.12.04090</a>
</div>
<div id="ref-keller2021paradox" class="csl-entry" role="listitem">
Keller, P., Tarkowski, A., 2021. The <span>Paradox</span> of <span>Open</span>. Open Future.
</div>
<div id="ref-kelley2020digital" class="csl-entry" role="listitem">
Kelley, E., Zandi, D., Krishnamurthy, R., Mehl, G., Novillo, D., Muneene, D., Nour, M., Taliesin, B., Leitner, C., Althauser, C., Schaefer, M., Ganesh, J., Marcelo, A., Ramkumar, P.S., Vota, W., Kumar, M., Joshi, S., Shehadeh, M.H., Nueno, V.P., Pye, E., Shokralla, M., 2020. Digital <span>Health Platform Handbook</span>: <span>Building</span> a <span>Digital Information Infrastructure</span> (<span>Infostructure</span>) for <span>Health</span>.
</div>
<div id="ref-kickbusch2021lancet" class="csl-entry" role="listitem">
Kickbusch, I., Piselli, D., Agrawal, A., Balicer, R., Banner, O., Adelhardt, M., Capobianco, E., Fabian, C., Gill, A.S., Lupton, D., Medhora, R.P., Ndili, N., Ryś, A., Sambuli, N., Settle, D., Swaminathan, S., Morales, J.V., Wolpert, M., Wyckoff, A.W., Xue, L., Bytyqi, A., Franz, C., Gray, W., Holly, L., Neumann, M., Panda, L., Smith, R.D., Stevens, E.A.G., Wong, B.L.H., 2021. The <span>Lancet</span> and <span>Financial Times Commission</span> on governing health futures 2030: Growing up in a digital world. The Lancet 398, 1727–1776. <a href="https://doi.org/10.1016/S0140-6736(21)01824-9">https://doi.org/10.1016/S0140-6736(21)01824-9</a>
</div>
<div id="ref-mamuye2022health" class="csl-entry" role="listitem">
Mamuye, A.L., Yilma, T.M., Abdulwahab, A., Broomhead, S., Zondo, P., Kyeng, M., Maeda, J., Abdulaziz, M., Wuhib, T., Tilahun, B.C., 2022. Health information exchange policy and standards for digital health systems in africa: <span>A</span> systematic review. PLOS Digital Health 1, e0000118. <a href="https://doi.org/10.1371/journal.pdig.0000118">https://doi.org/10.1371/journal.pdig.0000118</a>
</div>
<div id="ref-mandl2020push" class="csl-entry" role="listitem">
Mandl, K.D., Gottlieb, D., Mandel, J.C., Ignatov, V., Sayeed, R., Grieve, G., Jones, J., Ellis, A., Culbertson, A., 2020. Push <span>Button Population Health</span>: <span>The SMART</span>/<span>HL7 FHIR Bulk Data Access Application Programming Interface</span>. npj Digital Medicine 3, 1–9. <a href="https://doi.org/10.1038/s41746-020-00358-4">https://doi.org/10.1038/s41746-020-00358-4</a>
</div>
<div id="ref-mbugua2021adoption" class="csl-entry" role="listitem">
Mbugua, S., Korongo, J., Joram, M., Chuma Benard, M., Nambiro, A., 2021. Adoption of <span>ICT</span> to <span>Enhance Access</span> to <span>Healthcare</span> in <span>Kenya</span>. IOSR Journal of Computer Engineering 23, 45–50. <a href="https://doi.org/10.9790/0661-2302024550">https://doi.org/10.9790/0661-2302024550</a>
</div>
<div id="ref-mehl2023fullstac" class="csl-entry" role="listitem">
Mehl, G.L., Seneviratne, M.G., Berg, M.L., Bidani, S., Distler, R.L., Gorgens, M., Kallander, K.E., Labrique, A.B., Landry, M.S., Leitner, C., Lubell-Doughtie, P.B., Marcelo, A.D., Matias, Y., Nelson, J., Nguyen, V., Nsengimana, J.P., Orton, M., Otzoy Garcia, D.R., Oyaole, D.R., Ratanaprayul, N., Roth, S., Schaefer, M.P., Settle, D., Tang, J., Tien-Wahser, B., Wanyee, S., Hersch, F., 2023. A full-<span>STAC</span> remedy for global digital health transformation: Open standards, technologies, architectures and content. Oxford Open Digital Health 1, oqad018. <a href="https://doi.org/10.1093/oodh/oqad018">https://doi.org/10.1093/oodh/oqad018</a>
</div>
<div id="ref-mrema2021application" class="csl-entry" role="listitem">
Mrema, A., 2021. Application of <span>Digital Platform</span> to <span>Enhance Quality Improvement</span> in <span>Momcare Facilities</span> in <span>Manyara</span>. AIJR Abstracts.
</div>
<div id="ref-muinga2020digital" class="csl-entry" role="listitem">
Muinga, N., Magare, S., Monda, J., English, M., Fraser, H., Powell, J., Paton, C., 2020. Digital health <span>Systems</span> in <span>Kenyan Public Hospitals</span>: A mixed-methods survey. BMC medical informatics and decision making 20, 2. <a href="https://doi.org/10.1186/s12911-019-1005-7">https://doi.org/10.1186/s12911-019-1005-7</a>
</div>
<div id="ref-nsaghurwe2021one" class="csl-entry" role="listitem">
Nsaghurwe, A., Dwivedi, V., Ndesanjo, W., Bamsi, H., Busiga, M., Nyella, E., Massawe, J.V., Smith, D., Onyejekwe, K., Metzger, J., Taylor, P., 2021. One country’s journey to interoperability: <span>Tanzania</span>’s experience developing and implementing a national health information exchange. BMC Medical Informatics and Decision Making 21, 139. <a href="https://doi.org/10.1186/s12911-021-01499-6">https://doi.org/10.1186/s12911-021-01499-6</a>
</div>
<div id="ref-ochieng2024exploring" class="csl-entry" role="listitem">
Ochieng’, S., Hariharan, N., Abuya, T., Okondo, C., Ndwiga, C., Warren, C.E., Wickramanayake, A., Rajasekharan, S., 2024. Exploring the implementation of an <span class="nocase">SMS-based</span> digital health tool on maternal and infant health in informal settlements. BMC Pregnancy and Childbirth 24, 222. <a href="https://doi.org/10.1186/s12884-024-06373-7">https://doi.org/10.1186/s12884-024-06373-7</a>
</div>
<div id="ref-ogundaini2022systematic" class="csl-entry" role="listitem">
Ogundaini, O.O., Achieng, M.S., 2022. Systematic review: <span>Decentralised</span> health information systems implementation in sub-<span>Saharan Africa</span>. Journal for Transdisciplinary Research in Southern Africa 18, 1–10. <a href="https://doi.org/10.4102/td.v18i1.1216">https://doi.org/10.4102/td.v18i1.1216</a>
</div>
<div id="ref-onnx" class="csl-entry" role="listitem">
<span>ONNX</span> v1.15.0, 2023.
</div>
<div id="ref-openhie" class="csl-entry" role="listitem">
<span>OpenHIE Framework</span> v5.2-en, 2024. OpenHIE.
</div>
<div id="ref-otto2022designing" class="csl-entry" role="listitem">
Otto, B., Ten Hompel, M., Wrobel, S. (Eds.), 2022. Designing <span>Data Spaces</span>: <span>The Ecosystem Approach</span> to <span>Competitive Advantage</span>. Springer International Publishing, Cham. <a href="https://doi.org/10.1007/978-3-030-93975-5">https://doi.org/10.1007/978-3-030-93975-5</a>
</div>
<div id="ref-pedreira2023composable" class="csl-entry" role="listitem">
Pedreira, P., Erling, O., Karanasos, K., Schneider, S., McKinney, W., Valluri, S.R., Zait, M., Nadeau, J., 2023. The <span>Composable Data Management System Manifesto</span>. Proceedings of the VLDB Endowment 16, 2679–2685. <a href="https://doi.org/10.14778/3603581.3603604">https://doi.org/10.14778/3603581.3603604</a>
</div>
<div id="ref-prainsack2023beyond" class="csl-entry" role="listitem">
Prainsack, B., El-Sayed, S., 2023. Beyond <span>Individual Rights</span>: <span>How Data Solidarity Gives People Meaningful Control</span> over <span>Data</span>. The American Journal of Bioethics 23, 36–39. <a href="https://doi.org/10.1080/15265161.2023.2256267">https://doi.org/10.1080/15265161.2023.2256267</a>
</div>
<div id="ref-prainsack2022data" class="csl-entry" role="listitem">
Prainsack, B., El-Sayed, S., Forgó, N., Szoszkiewicz, Ł., Baumer, P., 2022. Data solidarity: A blueprint for governing health futures. The Lancet Digital Health 4, e773–e774. <a href="https://doi.org/10.1016/S2589-7500(22)00189-3">https://doi.org/10.1016/S2589-7500(22)00189-3</a>
</div>
<div id="ref-purnamajati2022data" class="csl-entry" role="listitem">
Purnama Jati, P.H., van Reisen, M., Flikkenschild, E., Oladipo, F., Meerman, B., Plug, R., Nodehi, S., 2022. Data <span>Access</span>, <span>Control</span>, and <span>Privacy Protection</span> in the <span>VODAN-Africa Architecture</span>. Data Intelligence 4, 938–954. <a href="https://doi.org/10.1162/dint_a_00180">https://doi.org/10.1162/dint_a_00180</a>
</div>
<div id="ref-purtova2023data" class="csl-entry" role="listitem">
Purtova, N., van Maanen, G., 2023. Data as an economic good, data as a commons, and data governance. Law, Innovation and Technology 0, 1–42. <a href="https://doi.org/10.1080/17579961.2023.2265270">https://doi.org/10.1080/17579961.2023.2265270</a>
</div>
<div id="ref-rieke2020future" class="csl-entry" role="listitem">
Rieke, N., Hancox, J., Li, W., Milletarì, F., Roth, H.R., Albarqouni, S., Bakas, S., Galtier, M.N., Landman, B.A., Maier-Hein, K., Ourselin, S., Sheller, M., Summers, R.M., Trask, A., Xu, D., Baust, M., Cardoso, M.J., 2020. The future of digital health with federated learning. npj Digital Medicine 3, 1–7. <a href="https://doi.org/10.1038/s41746-020-00323-1">https://doi.org/10.1038/s41746-020-00323-1</a>
</div>
<div id="ref-sanctis2022maintaining" class="csl-entry" role="listitem">
Sanctis, T.D., Etiebet, M.-A., Janssens, W., Graaf, M.H. van der, Montfort, C. van, Waiyaiya, E., Spieker, N., 2022. Maintaining <span>Continuity</span> of <span>Care</span> for <span>Expectant Mothers</span> in <span>Kenya During</span> the <span>COVID-19 Pandemic</span>: <span>A Study</span> of <span>MomCare</span>. Global Health: Science and Practice 10. <a href="https://doi.org/10.9745/GHSP-D-21-00665">https://doi.org/10.9745/GHSP-D-21-00665</a>
</div>
<div id="ref-scheibner2021revolutionizing" class="csl-entry" role="listitem">
Scheibner, J., Raisaro, J.L., Troncoso-Pastoriza, J.R., Ienca, M., Fellay, J., Vayena, E., Hubaux, J.-P., 2021. Revolutionizing <span>Medical Data Sharing Using Advanced Privacy-Enhancing Technologies</span>: <span>Technical</span>, <span>Legal</span>, and <span>Ethical Synthesis</span>. Journal of Medical Internet Research 23, e25120. <a href="https://doi.org/10.2196/25120">https://doi.org/10.2196/25120</a>
</div>
<div id="ref-shija2021access" class="csl-entry" role="listitem">
Shija, L., Yokoyana, J., Mrema, A., Bwakea, J., Kiwale, T., Massawe, N., 2021. Access to <span>Essential Maternal Health Commodities Key</span> to <span>Improving Quality</span> and <span>Adherence</span> to <span>Maternal Healthcare Regimes</span>: <span>Experience</span> from a <span>MomCare Project</span> in <span>Northern Tanzania</span>. AIJR Abstracts.
</div>
<div id="ref-sql-on-fhir" class="csl-entry" role="listitem">
<span>SQL</span> on <span>FHIR</span> speciification v0.0.1-pre, 2024.
</div>
<div id="ref-osi2024open" class="csl-entry" role="listitem">
The <span>Open Source AI Definition</span> v0.0.9, 2024. HackMD.
</div>
<div id="ref-witter2022learning" class="csl-entry" role="listitem">
Witter, S., Sheikh, K., Schleiff, M., 2022. Learning health systems in low-income and middle-income countries: Exploring evidence and expert insights. BMJ Global Health 7, e008115. <a href="https://doi.org/10.1136/bmjgh-2021-008115">https://doi.org/10.1136/bmjgh-2021-008115</a>
</div>
</div></section><section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes"><h2 class="anchored quarto-appendix-heading">Footnotes</h2>
<ol>
<li id="fn1"><p>We have argued the choice of FHIR as the common data model elsewhere, working paper to be submitted (<a href="https://plugin-healthcare.github.io/viewpoint-jimr/">link</a>).<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2"><p>Although the OpenHIE specification does not include details on dimensioning, these are typically the requirements that are used within the community. See <a href="https://wiki.ohie.org/display/CP/Interoperability+Layer+-+Use+Cases+and+Requirements">OpenHIE Community Wiki</a>.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</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');