Contents
1 Preface 1
1.1 Preface . . . 1
2 Introduction 3 2.1 About this Book . . . 3
2.2 GNU Health Functionality . . . 3
2.2.1 Deploying GNU Health: Centralized vs Distributed Installations. . . 4
3 Resources 5 3.1 More GNU Health Resources . . . 5
3.2 Website . . . 5 3.3 Mailing Lists . . . 5 3.4 Twitter . . . 5 3.5 IRC Channels . . . 5 3.6 Development Environment . . . 6 3.7 Google+ . . . 6
3.8 Community Demo Server . . . 6
4 First Steps 7 4.1 Terminology . . . 7
5 Navigation Area 11 6 Form fields and field types 13 6.1 Time to Practice . . . 14
7 The core module 15 7.1 The Core Module . . . 15
7.2 People before Patients . . . 16
8 Health Institutions 17 8.1 Introduction to Health Institutions . . . 17
8.2 Creating and Updating Health Institutions . . . 17
8.3 Health Institution Facilities . . . 18
8.3.1 Beds . . . 18 i
ii CONTENTS 8.3.2 Buildings . . . 18 8.3.3 Wards . . . 19 8.3.4 Operating Rooms . . . 19 8.3.5 Units . . . 19 9 Domiciliary Units 21 9.1 Introduction to Domiciliary Units . . . 21
9.2 The Domiciliary Units Form . . . 21
10 Individuals 23 10.1 The Individual . . . 23
10.2 Review of concepts . . . 23
10.3 Your first Individual in GNU Health . . . 23
10.3.1 Demographics . . . 24
10.3.2 Contact Information . . . 25
11 Families 26 11.1 The Family Concept in GNU Health . . . 26
11.2 Managing Families . . . 26
11.3 Searching Family Members . . . 27
12 Health Professionals 28 12.1 The Health Professional Concept . . . 28
12.2 Creating and Editing Health Professionals . . . 28
12.2.1 Party associated to a Health Professional . . . 29
12.2.2 The Internal User field . . . 29
12.2.3 Health Professional specific fields . . . 29
13 Medicaments 32 14 Prescriptions 33 14.1 About Prescriptions . . . 33
14.2 Information Stored in Prescriptions . . . 33
14.3 Prescription stock . . . 34
15 Vital Records 35 15.1 About Vital Records . . . 35
15.2 Birth Certificates . . . 35
15.3 Death Certificates . . . 36
15.4 Digital Signatures . . . 39
16 Immunizations 40 16.1 The Vaccine . . . 40
CONTENTS iii
16.2.1 Immunization Schedule Line . . . 41
16.3 The Vaccination Process . . . 42
16.4 Immunization Status Report . . . 43
16.5 Vaccine stock . . . 44
17 Configuration 45 17.1 The Configuration Section in GNU Health . . . 45
17.2 Diseases . . . 45 17.3 Genetics . . . 45 17.4 Imaging . . . 45 17.5 Procedures . . . 45 17.6 Laboratory . . . 45 17.7 Institutions . . . 46 17.8 Health Professionals . . . 46 17.9 Medicaments . . . 46 17.10Immunization Schedule . . . 46 17.11Misc . . . 46 17.11.1 Occupations . . . 46 17.11.2 Ethnicities . . . 46 17.11.3 Medical Specialities . . . 46 17.11.4 Recreational Drugs . . . 47
17.11.5 Pediatrics Growth Charts WHO . . . 47
17.11.6 Insurances . . . 47
18 Patient Management 48 18.1 Introduction to Patient Management . . . 48
18.2 Creating a party with the patient property . . . 48
18.2.1 Step 1: Party definition and demographics . . . 49
18.2.2 Step 2: Enabling the patient attribute in the party . . . 49
18.3 Listing the current patients . . . 49
18.4 Creating a patient record . . . 50
18.5 Printing a patient ID card . . . 50
19 Patient Evaluations 52 19.1 Introduction to Evaluations . . . 52
19.2 Evaluations History . . . 52
19.3 Evaluations Form . . . 53
19.3.1 Main Info Tab . . . 53
19.3.2 Clinical Tab . . . 53
19.3.3 Mental Status Tab . . . 54
19.3.4 Diagnosis Tab . . . 54
iv CONTENTS
20.1 Appointments . . . 55
20.1.1 Information stored per appointement . . . 55
20.1.2 List of all appointments . . . 56
20.1.3 List of appointments for a specific patient . . . 56
20.2 Hospitalizations . . . 57
21 Laboratory Management 59 21.1 Introduction to Laboratory Management . . . 59
21.2 Requesting a Laboratory Test . . . 59
21.2.1 Test Types . . . 60
21.3 Managing Laboratory Tests . . . 60
21.4 Storing Laboratory Test Results . . . 60
21.4.1 Main Info Tab . . . 61
21.4.2 Extra Info Tab . . . 62
21.5 Printing Laboratory Reports . . . 62
21.6 Configuration . . . 62
21.6.1 Lab Test Units . . . 63
21.6.2 Lab Test Types . . . 63
22 Financial Accounting 65 23 Analytic Accounting 66 24 Products and Services Management 67 24.1 Products . . . 67
24.1.1 Products basics . . . 67
24.1.2 Variants basics . . . 67
24.1.3 Creating new medication products . . . 67
24.2 Categories . . . 68
24.3 Invoicing Patients . . . 68
24.3.1 Step 1: Listing Health Services to be Invoiced . . . 68
24.3.2 Step 2: Creating the Invoice . . . 69
25 Stock Management 72 25.1 Basics of Stock Management . . . 72
25.2 Stock Locations . . . 72 25.3 Stock Movements . . . 72 25.4 Shipments . . . 73 25.4.1 Supplier Shipments . . . 73 25.4.2 Customer Shipments . . . 73 25.4.3 Internal Shipments . . . 73 25.5 Inventories . . . 74 26 Purchase Administration 75
CONTENTS v
27 Access Management 76
27.1 Access Management Overview . . . 76
27.2 Groups . . . 76
27.2.1 Members Tab . . . 77
27.2.2 Access Permissions Tab . . . 77
27.3 Users . . . 77
27.3.1 User Tab . . . 78
27.3.2 Actions Tab . . . 79
27.3.3 Access Permissions Tab . . . 79
27.3.4 Preferences Tab . . . 79 28 Socioeconomics 80 28.1 Introduction to Socioeconomics . . . 80 28.2 Main Tab . . . 80 28.3 Infrastructure Tab . . . 81 28.4 Family Tab . . . 81 29 Lifestyle 82 29.1 Introduction to Lifestyle . . . 82
29.2 Diet and Exercise Tab . . . 82
29.3 Addictions Tab . . . 83
29.4 Sexuality Tab . . . 84
29.5 Safety Tab . . . 84
30 Functioning and Disability 85 31 Gynecology 86 31.1 Introduction to Gynecology . . . 86
31.2 General Tab . . . 86
31.3 Screening Tab . . . 87
31.3.1 Mammography History . . . 87
31.3.2 PAP Smear History . . . 87
31.3.3 Colposcopy History . . . 87
32 Obstetrics 88 32.1 Introduction to Obstetrics . . . 88
32.2 General Pregnancy Information . . . 88
32.3 Prenatal Evaluations . . . 89
32.4 Perinatal and Intrapartum Information . . . 90
32.4.1 Main Tab . . . 91
32.4.2 Additional Info Tab . . . 92
32.5 Puerperium Monitor . . . 93
vi CONTENTS 33.1 Introdcution to Genetics . . . 95 33.2 Genetic Risks . . . 95 33.3 Family History . . . 97 34 Surgery 98 34.1 Introduction to Surgery . . . 98 34.1.1 ICD-10-PCS . . . 98
34.2 Surgeries per Patient . . . 98
34.3 All Surgeries . . . 99
34.4 Surgeries Form . . . 99
34.4.1 Revised Cardiac Risk Index (RCRI) . . . 101
35 Pediatrics 103 35.1 Introduction to Pediatrics Section . . . 103
35.2 Neonatology . . . 103
35.2.1 Creating a Newborn Record . . . 103
35.2.2 Newborn and Mother Wristbands . . . 104
35.3 PSC (Pediatrics Symptom Checklist) . . . 105
36 Nursing 107 36.1 Introduction to Nursing . . . 107 36.2 Roundings . . . 107 36.2.1 Main Tab . . . 107 36.2.2 ICU Tab . . . 107 36.2.3 Procedures Tab . . . 107 36.2.4 Medication Tab . . . 107
36.2.5 Stock Moves Tab . . . 107
36.3 Ambulatory Care . . . 107
36.3.1 Main Tab . . . 107
36.3.2 Other Tab . . . 108
36.3.3 Medication Tab . . . 108
36.3.4 Stock Moves Tab . . . 108
37 Inpatient Management 109 37.1 Introduction to Inpatient Management . . . 109
37.2 Admission Process . . . 109
37.3 Administrative Data Tab . . . 109
37.3.1 Assigning a Bed . . . 110
37.4 Nutrition Tab . . . 110
37.4.1 Managing Beliefes . . . 111
37.4.2 Managing Therapeutic Diets . . . 111
37.5 Medication Plan Tab . . . 112
CONTENTS vii
38 Intensive Care Unit 113
38.1 Introduction to the ICU Functionality . . . 113
38.2 Patient ICU Information . . . 113
38.2.1 APACHE II . . . 113
38.2.2 ECG . . . 115
38.2.3 GCS . . . 116
38.3 Patient Rounding . . . 116
38.3.1 Neurologic . . . 116
38.3.2 Respiratory (incl. X-Ray) . . . 117
38.3.3 Drainages . . . 117
38.3.4 Cardiovascular . . . 117
38.3.5 Blood and Skin . . . 117
38.3.6 Digestive and Abdomen . . . 117
39 Neglected Tropical Diseases 118 39.1 Introduction to Neglected Tropical Diseases . . . 118
39.2 Chagas Disease . . . 118
39.2.1 Chagas Related Surveys . . . 118
39.2.2 Chagas Related Laboratory Tests . . . 119
39.3 Dengue Fever . . . 120
39.3.1 Dengue Related Surveys . . . 120
39.3.2 Dengue Related Laboratory Tests . . . 121
40 Reporting 122 40.1 Introduction . . . 122
40.2 Demographics Summary . . . 122
40.3 Patient Evaluations . . . 122
40.4 Top Diseases . . . 122
40.5 Injury Surveillance System Registration . . . 122
40.6 Specialties by health professionals . . . 123
40.7 Evaluations Report . . . 123
41 Demographics 124 42 Epidemiology 125 43 Installation 126 43.1 Requirements . . . 126
43.2 Installing GNU Health on GNU/Linux and FreeBSD . . . 126
43.2.1 Operating System requirements . . . 126
43.2.2 Creating the Operating System User . . . 126
43.2.3 Verify PostgreSQL authentication method . . . 127
viii CONTENTS
43.2.5 Downloading and Installing GNU Health . . . 128
43.3 Booting up the Tryton Server . . . 129
43.4 Installation of the Tryton Client . . . 129
43.4.1 Standard Method . . . 129
43.4.2 Alternative Method (PIP) . . . 130
43.4.3 Setting the Tryton Client Tabs Position for GNU Health . . . 130
43.4.4 Creating the GNU Health database . . . 130
43.5 Logging into the Application . . . 132
43.6 Installing the Default Modules . . . 132
43.7 Creating a Company . . . 134
44 Administration 136 44.1 About the Administration Section . . . 136
44.2 Overview . . . 136 45 User Interface 137 46 Models 138 47 Sequences 139 48 Scheduler 140 49 Localization 141 49.1 Translating GNU Health . . . 141
49.2 About Transifex . . . 141
49.3 Installation of Language Packs . . . 141
49.4 Setting the User Language . . . 142
50 Modules 144 50.1 Installing Extra Modules . . . 144
50.1.1 Installation Process . . . 144 50.1.2 Dependencies . . . 144 50.2 Available Modules . . . 144 50.3 Custom Modules . . . 145 51 Users 146 52 Countries 147 53 WebDAV 148 54 Central Authentication 149 54.1 Introduction . . . 149 54.1.1 Components . . . 149
CONTENTS ix
54.2 Installation . . . 149
54.2.1 Creating the Organization and Users on the LDAP Server . . . 150
54.2.2 Configuring LDAP in GNU Health . . . 150
55 Patches and Patchsets 152 55.1 About GNU Health Patchsets . . . 152
55.2 Patches vs Patchsets . . . 152
55.2.1 Patches . . . 152
55.2.2 Patchsets . . . 153
55.3 Criteria for a New Patchset Release . . . 153
55.4 Applying Patchsets . . . 153
56 Upgrade 155 56.1 About GNU Health Upgrades . . . 155
56.2 Gathering Information . . . 155
56.3 Prepare your Upgrade . . . 156
56.4 The Upgrade Process . . . 156
57 Contributing 157 57.1 Contributors Wanted! . . . 157
57.2 Translating the Software . . . 157
57.3 Writing and Translating the Documentation . . . 157
57.4 Reporting Bugs . . . 157
57.5 Coding . . . 157
57.5.1 Obtaining Your Copy of the Code . . . 158
57.5.2 Coding style . . . 158
57.5.3 Customizing and Creating Your Own Modules . . . 158
57.5.4 Submitting Patches . . . 158
58 Backups and High-Availability 159 58.1 About the GNU Health Control Center . . . 159
58.2 Invoking gnuhealth-control . . . 159
58.3 Backups . . . 159
58.4 Updates . . . 159
59 Security 161 59.1 Securing Your GNU Health Environment . . . 161
59.2 Access Control . . . 161
59.2.1 Standard Ports . . . 161
59.2.2 Serverpass: The Server Password Utility . . . 161
59.3 Public-key Cryptography in GNU Health . . . 161
59.3.1 GNU Health Cryptographic Module . . . 162
x CONTENTS
60 Troubleshooting 165
61 FHIR REST server 166
61.1 About FHIR and REST . . . 166
61.2 Installation . . . 166
61.3 Configuration . . . 166
61.4 Security . . . 167
61.5 Running the Server . . . 167
61.6 Troubleshooting . . . 167
61.6.1 Cannot connect to database . . . 167
61.6.2 No database with that name . . . 167
62 Using the FHIR REST server 168 62.1 FHIR Overview . . . 168
62.2 URL Structure . . . 168
62.3 Authentication . . . 169
62.4 Searching / Listing . . . 169
62.5 Test Server Examples . . . 169
63 Synchronization Guide 170 63.1 Scope of this Document . . . 170
63.1.1 Definitions . . . 170
63.2 Installation of Satellites and Central instance . . . 170
63.2.1 Satellites . . . 170
63.2.2 Running the Synchronization Engine on Satellite Instances . . . 171
63.3 Technical Documentation . . . 172
63.3.1 Developers “Mini-Guide” to the Synchronization Engine . . . 172
64 Release Process 173 64.1 Introduction to the GNU Health Release Process . . . 173
64.1.1 Stages of the Release Process . . . 173
64.2 Upcoming Release Schedule . . . 173
64.3 Security fixes . . . 173
65 Different ways to test GNU Health 174 65.1 About this page . . . 174
65.2 Option 1: Connect to the Demo Database . . . 174
65.2.1 What to do . . . 174
65.2.2 Advantages . . . 174
65.2.3 Disadvantages . . . 174
65.3 Option 2: Run GNU Health from CD/DVD or USB Stick . . . 174
65.3.1 What to do . . . 174
CONTENTS xi
65.3.3 Disadvantages . . . 175
65.4 Option 3: Run GNU Health in a Virtual Machine . . . 175
65.4.1 What to do . . . 175
65.4.2 Advantages . . . 175
65.4.3 Disadvantages . . . 175
65.5 Option 4: Run GNU Health from Docker (Lightweight Containers) . . . 176
65.5.1 What to do . . . 176
65.5.2 Advantages . . . 176
65.5.3 Disadvantages . . . 176
66 The Demo database 177 66.1 Introduction to the Demo Database . . . 177
66.2 The Zenon-Betz Family . . . 177
66.2.1 Demographics Information . . . 177
66.2.2 Patient Information . . . 178
66.2.3 Other Information . . . 178
66.3 Online Demo Database . . . 178
66.4 Local Demo Database . . . 179
66.4.1 Manual Installation . . . 179
66.4.2 Installation Using Proteus Demo Script . . . 179
66.5 References . . . 180
67 The Live-CD 181 68 The Live-CD 182 68.1 Download the Live-CD . . . 182
68.2 Install the Live-CD . . . 182
68.2.1 USB-Stick / Hard Disk Image . . . 182
68.2.2 ISO-Image / CD . . . 183
68.3 Install the Live-CD to your hard drive . . . 183
69 Virtual Machine Images 184 69.1 Running the Virtual Machine as Server . . . 184
69.2 Adjustments . . . 184 70 Glossary 186 70.1 ICD-10-PCS . . . 186 70.2 Company . . . 186 70.3 ECG . . . 186 70.4 Employee . . . 186
70.5 Glasgow Coma Scale . . . 186
70.6 GSC . . . 186
xii CONTENTS 70.8 Inventory . . . 187 70.9 Module . . . 187 70.10Move . . . 187 70.11Party . . . 187 70.12Patient . . . 187
70.13Pediatrics Symptom Checklist . . . 187
70.14Person . . . 187
70.15Person Unique Identification Number . . . 187
70.16Product . . . 187 70.17PSC . . . 188 70.18PUID . . . 188 70.19QR Code . . . 188 70.20Shipment . . . 188 70.21User . . . 188 71 FAQ 189 71.1 General Questions . . . 189
71.2 Concepts of GNU Health and Tryton . . . 189
71.3 Demo Database . . . 190
72 Operating System-Specific Notes 191 73 Arch Linux 192 73.1 Install dependencies . . . 192
73.2 Initialize the DB cluster . . . 192
73.3 Start and enable the PostgreSQL service . . . 192
74 Debian 193 74.1 Install dependencies . . . 193
75 FreeBSD 194 75.1 Install dependencies . . . 194
75.2 Link Python and cracklib dictionaries . . . 194
75.3 Init PostgreSQL server . . . 194
76 OpenSUSE 195 76.1 Add Password Management Repository . . . 195
76.2 Install dependencies . . . 195
77 Ubuntu 196 77.1 Install dependencies . . . 196
78 Trisquel 197 78.1 Install dependencies . . . 197
CONTENTS xiii
79 Packaging Guidelines 198
80 Community Pages 199
80.1 Text and image sources, contributors, and licenses . . . 200
80.1.1 Text . . . 200
80.1.2 Images . . . 202
Chapter 1
Preface
1.1 Preface
Regardless of the remarkable achievements in technology, thousands of children will die today from preventable diseases. Infectious diseases such as malaria, chagas, AIDS, tuberculosis or infectious diarrhea destroy millions of families in developing countries. Noncommunicable diseases including obesity, diabetes, heart disease, cancer or major depressive syndrome hit both the North and the South, although with much higher prevalence and incidence among the underprivileged sectors. Equally important are the alarming levels of child labor, human trafficking and sex slavery, family violence, child abuse or drug addiction. Complex, multi-etiological and anthropological issues also exist that desperately need to be addressed.
We need a change of paradigm: We need to move away from the reactive Model of Disease, to the proactive Model of Health . Many countries lack good public health, sometimes because they put the focus on the private sector; sometimes because they give too much emphasis to technology. The most sophisticated technology will never beat good Primary Health Care policies. Education, good nutrition, family affection, physical exercise, and sanitary hous-ing conditions are the best and most sustainable public policies one can make. The concept of Integrative Medicine is always present in GNU Health.
I started the GNU Health project in 2008 to improve Primary Health Care (PHC) in rural communities. Today GNU Health has grown to a full Health and Hospital Information System, but the spirit remains the same. GNU Health complements PHC, but never will replace the work of the mother, teacher, nurse, doctor or social worker. What GNU Health does well is handling and processing large amounts of data. GNU Health manages demographics; patient evaluations, hospitalizations, clinical history; genetic and hereditary risks; epidemiology and health center resources (stock, finances, human resources, pharmacies, laboratory .. ), to name a few resources. Computing power and data processing improve team work and optimize health promotion and disease prevention campaigns. For example, GNU Health allows quick identification of new TBC or Dengue outbreaks by showing the index cases in a map, in realtime. It can show the trends in infestation level of vectors that transmit Chagas disease in Domiciliary Units; It can cross indicators in different communities, and relate Social determinants of Health in many conditions (family violence, teenage pregnancy, child mortality, ... ).
GNU Health is a philosophy. It’s putting Free Software as a public good, and as an integral part of Public Health. It’s about equity, community work and solidarity. It’s about empowering the health professionals, their health centers and their communities. It’s about putting in action many aspects from theAlma-Ata Declaration.
GNU Health is about embracing System of Health paradigm, instead of the conventional system of disease that many countries are inmersed today.
I hope you enjoy this book, and I count on you to join our growing community of academic institutions, NGOs, public hospitals, private companies and Multilateral organizations. Free Software in Health Care is here to stay. eHealth for all !
2 CHAPTER 1. PREFACE
GNU Health paradigm of System of Health
Luis Falcón, MD GNU Solidario
Chapter 2
Introduction
2.1 About this Book
This book provides an introduction to GNU Health, The Free Health and Hospital Information System. Unlike traditional books, this Wikibook will be updated with the latest stable GNU Health version. Health is dynamic by nature, so is GNU Health.
Versioning: The book will include functionality from the upcoming version, several weeks before the stable release. This means that some texts and pictures in the book belong to the new version.
The book is organized in the following sections: • Introduction to GNU Health
• Functional guide: Philosophy behind the project and the core functionality. Provides the information on how to approach a GNU Health implementation.
• Modules in Detail: Information and instructions for specific modules. Each modules encompasses functionality for a speciality (pediatrics, surgery, gynecology, socioeconomics ... )
• Technical: Installation manual, administrator’s guide
If you are starting with GNU Health, you should read the book in a linear, sequential fashion. It’s the best way to understand the software, the project and how to implement it.
2.2 GNU Health Functionality
The main areas of GNU Health are:
• Individual and community management: demographics, domiciliary units, families, operational areas and sectors, ...
• Patient management: Socioeconomics, lifestyle, encounters / evaluations, hospitalizations, lab reports, clin-ical history, ...
• Health center management: Finances, stock, pharmacy , laboratory, beds, operating rooms, appointments, supply chain management, human resources, ...
• Information management: Reporting, Demographics and Epidemiology
These areas involve a multi-disciplinary teams, with different responsibilities. For example, the individual demo-graphics and status of the domiciliary units (DU) can be collected by social workers; the patient management by
4 CHAPTER 2. INTRODUCTION
health professionals ; the health center management by administrative personnel and accountants ; and the Informa-tion produced by the health center can be processed and managed by the Ministry of Health authorities.
This is just an example to show the importance of team work in GNU Health to get be best results in your community.
2.2.1
Deploying GNU Health: Centralized vs Distributed Installations
GNU Health is scalable in functionality, database size and transactional volume. For instance, you can install GNU Health in a single doctor office, or in country public hospitals network. Depending the type of deployment, you will think about a centralized (single instance) vs a distributed installation.
• Single GNU Health Instance: All the information resides in a single database, and it will be accessed via network from different workstations from the same health center (local area network) or from different health centers.
• Distributed GNU Health instances: Under this scenario, each health center has its own database instance, and information can be synchronized among health centers. This would be the case when you want to deploy GNU Health in a network of hospitals, where the communication infrastructure is suboptimal.
Needless to say, choosing the deployment method requires careful study of resources (hardware, network, human resources, security and access control, backup and disaster recovery policies, ... ) that goes beyond the scope of this book. The two types of installations have pros and cons.
Sample Patient ID card generated by GNU Health
Unique Patient ID: In hand-written histories and in some electronic medical records, is not uncommon to find duplicate patients or duplicate medical records. This scenario is not only costly, but it may represent a risk to the patient.
The other problem people face in many countries is data isolation. That is, health centers don't communicate to each other, resulting in a different medical history on each center. In other words, in many health care systems today, you are a different person and patient on each health center you visit.
GNU Health uses a unique person and patient identifier, that does not allow the duplication of either indi-viduals or patient medical history at the health center. It allows to export the information to the patient card, and it provides the framework to synchronize data between health centers. For quick patient identification in different health care network, the patient ID can be read, for example, with a QR reader, speeding up the registration process and avoiding common human errors.
If you plan to use a distributed environment in your health network, you can find more information about in theGNU Health Synchronization Guide.
Chapter 3
Resources
3.1 More GNU Health Resources
Besides the GNU Health documentation on Wikibooks (which you are reading right now), there are several other resources for the GNU Health community.
3.2 Website
The official GNU Health Website can be found athttp://health.gnu.org
3.3 Mailing Lists
There are several mailing lists for information exchange via email: • health: General questions and discussions about GNU Health • health-announce: GNU Health releases and events
• health-dev: Development, requests and bugs
• health-es: General questions and discussions about GNU Health in Spanish • health-fr: General questions and discussions about GNU Health in French • health-pt: General questions and discussions about GNU Health in Portuguese To subscribe to these mailing lists, please visithttps://savannah.gnu.org/mail/?group=health
3.4 Twitter
For regular news updates we suggest that you follow GNU Health on Twitter athttps://twitter.com/gnuhealth
3.5 IRC Channels
You can find live help at IRC in the following channels: • #gnu-health: English
6 CHAPTER 3. RESOURCES
• #gnu-health-es: Spanish
You can use any IRC client orFree node web interface
3.6 Development Environment
On August 26th, 2011, the Free Software Foundation adopted GNU Health as an official GNU project. Since then, the development environment is hosted at GNU Savannah. Besides the mailing lists, here you can post bugs, tasks and check out the latest development version.
http://savannah.gnu.org/projects/health
3.7 Google+
The GNU Health community on Google’s social networking platform Google+ can be found athttps://plus.google. com/communities/104024590265963842407
3.8 Community Demo Server
This server is in Europe and serves as a demo server to practice and see a running system. You can find more information in theOnline Demo Databasesection of this book.
Chapter 4
First Steps
4.1 Terminology
Before we start the implementation process, it is important to get familiar with the terminology commonly used in the rest of this book. At the beginning some words might be a bit puzzling, but with a bit of practice, you will find this terminology quite logical.
First you should know that GNU Health builds upon other software. Even if you are not a technical personal, it might be helpful to understand that GNU Health is an extension to Tryton, a general enterprise resource planning system (or ERP for short) for almost any type of company or organisation. Tryton is developed in the Python programming language, and it stores all its data in a PostgreSQL database.
The following concepts are essential to understand how GNU Health works:
Company. An example of a Party
• Party: In GNU Health, a party is an entity. An abstract concept to define someone or something that has legal 7
8 CHAPTER 4. FIRST STEPS
status. It’s the unit of the relationship in Tryton. Some examples of Parties are: • Patients
• Companies
• Health professionals • Health centers
• Model: The model defines each object in GNU Health. Models define the database objects (tables). gnuhealth.patient is a model example.
• Field: The building blocks of the model. For example: age and sex are gnuhealth.patient fields.
• View: Views are the representation of the model on the screen. Most models will have an individual form to accept data into the model and display data out from the model.
• Tree: The list format of the model. The tree view allow us to search select multiple records.
Example of a Tree list
• Form: The representation of the model on the screen that allows you to input data.
• Table: The model representation at the database server. The model gnuhealth.patient is mapped in the table gnuhealth_patient in postgreSQL.
• Record: Each unique entry in a particular database table. For example Ana Betz is a record on the gnuhealth_patient table in PostgreSQL.
• Module: Modules are programs that provide specific functionality. GNU Health provides different modules to meet your health center needs. Example of modules are Socioeconomics, Genetics and Surgery. You should only install the modules that are actually needed for your center.
• Report: Reports allows you to dynamically print documents in Open Document / LibreOffice format (ODF), Portable Document Format (PDF) or even directly to the printer.
• Action: Actions are processes excecuted upon one or more selected records. • Notebook: A tabbed group of forms designed to make navigation easier.
4.1. TERMINOLOGY 9
Form view of the same record
10 CHAPTER 4. FIRST STEPS
Chapter 5
Navigation Area
Now is time to identify the components of the GNU Health Screen. In the following screenshot we have marked the main sections :
Navigating GNU Health
• Main Menu : We can navigate among the different functionalities. Configuration, Patients, Financial, ... You can deactivate the main menu (useful in low resolution devices) by pressing Ctrl+T
• Tabs : Tryton allows you to have multiple records open at the same time. The section “Tabs” of the screenshot shows the current form.
• Actions : Under the Tabs section you will find different icons that act upon the current record. You can, for instance, create a new record, generate a report, change the view, select related records associated to this patient (appointments, lab tests... ).
• Record form : This is where you see and input the information. Notice that you can have tabbed forms (notebooks) in the lower half of the form, which allows quick and easy navigation. In this example some of the tabs within the records are main, medication, diseases, surgeries, socioeconomics and gynecological information. The upper side of this form is static, so the health professional has the most relevant information about the patient always visible.
12 CHAPTER 5. NAVIGATION AREA
• Status bar : The lower side of the screen shows the status bar. From left to right, these are fields : • User name : In this case we logged in as Administrator
• Organization Name : GNU Solidario Hospital
• Requests : Tryton has an internal messaging system. You will get notifications in realtime.
• Server Information : The lower right section gives you login and server information. In this example, it shows “admin@localhost:8000/demo". admin is the login name, localhost the name of the GNU Health server, 8000 is the port where connects and demo is the database name.
Chapter 6
Form fields and field types
Let’s now go through the most relevant field types and how to properly use them. We will use the previous screenshot of the patient as the example.
• Text fields : These type of fields allow us to enter a lot of information. You will see them normally like large boxes. In our example, the field under “Patient Allergies and Critical Information” is a text field.
• Character fields : These type of fields are similar to the Text fields, but with a limited size. There are few character fields and none in this example. The diet type in the lifestyle section or the Gene ID on genetics are example for character fields.
• Date Fields : These fields will open a calendar when clicked, so you can choose the date. Alternatively, you can enter the date manually. The date of birth is a Date field.
• DateTime Fields : Similar to the date fields, but with the addition of time. An example of this field is the Date/time of birth of the newborn, in the neonatology module.
• Integer fields : These fields allow only integer numbers. They show a “0” by default. An example is Minutes of physical exercise per day
• Float fields : You can enter decimal numbers. The body temperature is one example of a float field.
• Function fields : These are special fields, in the sense that they are calculated in real time, depending, most of the time, on the values of other fields. For example, the Patient Age is a function field. Notice that the field has a grey background, meaning that is read-only. It will calculate the current patient age in years/months/days depending on the patient date of birth. Another example of function field is the Hospitalization Status of the patient.
• Selection fields : These fields will let you choose from a list of options. For example, the patient Sex or the blood type are selection fields. This type of field minimizes typing error.
• Relational fields : These fields retrieve information from a related model. They are of the form One2Many or Many2One. Relational fields are important to keep the uniqueness of data. By using this type of fields, you link the ID of an existing record, without duplicating information, to another record. The patient is a relational (One2Many) field. It relates to the the party model, from where it gets all the administrative data (Social security number, address, etc... ).
Shortcuts : [F2] will open the related record and [F3] will create a new record
• Required fields : These fields are mandatory. You must enter information or else the record won't be saved. You can quickly identify the required fields because they have a blue background. The Patient field is a required field.
14 CHAPTER 6. FORM FIELDS AND FIELD TYPES
6.1 Time to Practice
Important : Make sure you are in your demo database. This demo database that you created has no important information. You can put anything you want. You can even delete it and recreate it. Just make sure you don't use a production database for your tests. One way to prevent accidentally entering the production database is to have a different password for your demo database, this way if you select the wrong database, you won't be able to login. If you do not have a demo database yet, please refer to the chapterDifferent ways to test GNU Healthto learn how to create your own testing environment.
It’s been a lot of information! Now is time to play around with all this information. With the information try the following :
1. Navigate in the Main menu 2. Open the Configuration Submenu
Chapter 7
The core module
7.1 The Core Module
As we have mentioned already in previous sections of the book, GNU Health is composed of different modules which will provide specific functionality to your health center.
The module health is at the center of GNU Health. This module contains the core models and classes, so the rest of the modules will just inherit them. This gives modularity and scalability, without leaving behind the most important building blocks in public health. Some of the models found in the core module are:
GNU Health modular design
• Individuals • Families
• Domiciliary Units
16 CHAPTER 7. THE CORE MODULE
• Operational Sectors • Health Centers • Diseases • Patient
• Patient Evaluation / Encounters • Medicaments
• Treatments
There are many others models in the core module, but this subset will give you an idea of the concept. If you are not a programmer, you don't really have to worry much about how GNU Health deals internally with dependencies and inter-module communication. For example, if you want to install the pediatrics module health_pediatrics, it will automatically mark the core module health for installation, as a dependency.
To learn more about GNU Health modules, please refer to theModuleschapter.
In this documentation, we will cover the functionality of the core module first before exploring the possibilities of the other modules.
7.2
People before Patients
If we want to be good in a Public Health system, the first thing we need to do is knowing our population. As I say, we need to deal with people before patients . Whenever possible, the health center should have a census, and the list of domiciliary units (DU) and their conditions, at least of those habitants that are part of the operational sector covered by the health center.
From a functional and implementation point of view, we should see the GNU Health core module objects as the first ones to be assessed. The process of collecting this information will get our health center involved with the community. In the next chapters we will be covering how to setup a Domiciliary Unit (DU); an Individual; the habitants of a DU; Families ; Operational Areas and Operational Sectors.
Once you have that information in place, you will be able to give a new attribute to the individual when she or he first come to your office, the patient attribute. As you can see, there are precious information and actions that can be done in Public Health before dealing with a single patient.
Chapter 8
Health Institutions
8.1 Introduction to Health Institutions
The Health Institution plays a central role in GNU Health. As a matter of fact, is the first thing you will have to create in the installation.
Since version 2.6, the health institution is a model. It is linked to the party model, but it has many other attributes.
8.2 Creating and Updating Health Institutions
The Institutions form in GNU Health
18 CHAPTER 8. HEALTH INSTITUTIONS
The very first health institution that you create is special because it is also your company. Please refer to the“Create a Company” section in the “Installation” chapterfor more details.
Health institutions can be accessed in the Health → Institutions section.
8.3 Health Institution Facilities
Selecting the health institution related facilities is done from the main institution form.
A health institution can have multiple facilities and resources, such as buildings, wards, operating rooms, beds or units.
The best way to access the health institution facilities is by clicking on the Relate button in the Institutions form as shown in the screenshot. One of the benefits of using related records from the institution form is that the related facility will contain the parent center, optimizing data entry and minimizing human error.
8.3.1
Beds
Beds are the most basic facilities in a health institution. Creating a bed record for each physical bed available is important for capacity planning and for finding a patient. Each bed belongs to a ward.
Configuring Beds
Bed records in GNU Health can be managed in the Health → Configuration → Institutions → Beds section. For each Bed record you need a corresponding Product Variant record (which stands for the individual bed) plus a Product record (which stands for the bed category and defines its price).
Note: If you are not familiar with products in Tryton, there is more information about this concept in the chapter
“Products and Services Management”. But if you just want to configure some beds at this moment and don't care about the details, then simply read on.
Configuring beds in GNU Health is a three step process:
1. For every category of beds, create a product record and enter the price the patient will be charged. Example: 2. For every bed available in your health institution, create a product variant record and check the Bed checkbox. Every variant will need a code as an identifier, but you are free to use any combination of characters and numbers to match the numbering scheme in your institution. Example:
3. For every bed available in your health institution, create a bed record and assign it to the corresponding product variant record. A bed record stores additional information about a bed like its status (free, reserved, occupied, ...) or the ward it belongs to. If you skip this step you will not be able to assign a patient to a bed in the hospitalization process!
8.3.2 Buildings
8.3. HEALTH INSTITUTION FACILITIES 19
Configuring Buildings
Creating and editing buildings is straight forward. The only thing to keep in mind is that both the name and the code of a building need to be unique within a given health institution.
8.3.3
Wards
Each ward belongs to one building (the physical location) and one unit (the organisational entity). Configuring Wards
Configuring wards is staight forward. However, the Wards form allows you to enter a lot of details about a ward: • Name: The ward name is mandatory and must be unique within a health institution.
• Building: Link to an existing building or create a new one. • Floor Number: Indicate the floor within a building. • Unit: Link to an existing unit or create a new one.
• Number of beds: This field is for information only. It does not reflect the number of beds you have configured for your health institution.
• Gender: Indicate if a ward is gender specific. (If not, set it to “Unisex” which is the default value.)
• Status: Indicate if a ward has capacity for more patients. (Choose between “Beds available”, “Full”, or “Not available”.)
The wards form allows you to indicate some special features as well: • Telephone access • Air conditioning • Private bathroom • Guest sofa-bed • Television • Internet access • Refrigerator • Microwave
8.3.4
Operating Rooms
Each operating room belongs to one building (the physical location) and one unit (the organizational entity). Configuring Operating Rooms
The configuration of operating rooms is straight forward. A name is mandatory and must be unique within a given health institution. Assigning an operation room to a building and/or a unit is optional. Further information about the operation room can be stored in the Extra Info field.
8.3.5 Units
20 CHAPTER 8. HEALTH INSTITUTIONS
Configuring Units
Creating and editing units is straight forward. The only thing to keep in mind is that both the name and the code of a unit need to be unique within a given health institution.
Chapter 9
Domiciliary Units
9.1 Introduction to Domiciliary Units
GNU Health Domiciliary Unit screenshot on version 2.0rc1
A Domiciliary Unit (DU) represents a human dwelling. It is composed of intra (domiciliary) and extra (peridomicil-iary) spaces. The DU is a physical entity that denotes the place where one or more people live regularly.
Since it is a physical location, it can always be geo-referenced by latitude and longitude, and many times it will have an associated address (street, ZIP code, city). This DU information should always be provided, since it is key determinant of health. Diseases like dengue fever and Chagas disease are intimately related to the DU condition (seeNeglected Tropical Diseasesfor details).
9.2 The Domiciliary Units Form
The Domiciliary Units form can be found at Health → Demographics → Domiciliary Units in the main navigation of GNU Health.
A domiciliary unit can be described by the following information: 21
22 CHAPTER 9. DOMICILIARY UNITS
• Code: A unique identifier of the dwelling. This field is required. • Description: Short description of the DU.
• Address: Street, number, district, municipality, city, state and country. • Latitude and Longitude
GNU Health integration of the Domiciliary Unit with OpenStreetMaps.
• OSM Map URL: The OpenStreetMap URL is created automatically from the coordinates or the DU address. (If latitude and longitude are not provided, then the OSM Map URL will be generated based on the address components. However, latitude and longitude will usually give you a more accurate reference.)
• General Conditions: A summary of the living conditions. This field should be filled in all the times, since it’s one of the most descriptive about the DU.
• Type of Dwelling: Single house, apartment, townhouse, ... • Infrastructure: Electricity, gas, potable water, sewers, ...
• Operational Sector: The area that this DU belongs. Very important to know which operational area is respon-sible to take different health care actions (health promotion, healthcare area, ambulace action region, ...) • Members: In this section a list with all inhabitants of a DU is shown. They may be or may not be family
Chapter 10
Individuals
10.1 The Individual
It’s time to enter the essential unit of GNU Health, the person. We take the person as a unique individual, yet, somebody that is part of a family, interacts with the community and makes up our society. This entity is so important that it’s impossible to achieve good public health programs without information about the individuals. This concept that might seem trivial, is very often overlooked.
10.2 Review of concepts
Tree view of Parties in GNU Health on Tryton framework
We mentioned in theFirst Stepsthe concept of Party. A party is an abstract entity, which attributes will differentiate a health center from a person, or a person that is a doctor, a patient or both. The concept of party is extremely simple, yet very powerful and versatile.
At this point is important to go back and refresh theTerminologyused in GNU Health.
10.3 Your first Individual in GNU Health
Follow the menu : Party -> Parties
24 CHAPTER 10. INDIVIDUALS
You will be presented with a Tree view (listing) of the parties in the system. Take a look at the screen shown in this section. I have selected / Highlighted three parties. “Ana Betz”, “Cameron Cordara” and “GNU Solidario Hospital”. They are all parties (entities), but their attributes make Ana a patient, Cameron a doctor and GNU Solidario Hospital a Health Institution.
Of course, under this model, you can have, for instance, a health professional that is also a patients. Don't forget that doctors are people :-)
To create a new record, click on the new record icon, or type Ctrl+N. You will be presented with the new party form view.
In a multidisciplinary team, the following information is usually done by the administration office, the front desk or sometimes by the social workers.
In this example, we will focus on Ana Betz. Let’s go over the main fields:
• Name: This is a required field, denoted by the blue background. Required fields must be entered otherwise you won't be able to save the record.
• Lastname: Enter the lastname as appears in the ID card. Some countries use only the father’s name, other use a combination of the father and the mother.
• Alias: Nickname (if any) of the person. Surprisingly enough, in many places around the world, people use nicknames to refer a particular person, and sometimes they don't know the real name. If that person has an alias / nickname, you should enter it on the system. It might be key to know about a missing person.
• Party Attributes: At this point, set the Person checkbox. Just check this one. Don't enable any other at this point.
Before going into the patient demographics. save your work. As a general rule, is important so save your work while working on records, to avoid losing your unsaved data, specially in long records. To save the person, click on the save this record icon or type Ctrl+S.
10.3.1
Demographics
The information entered in this section is very important at both individual and population level. The health profes-sionals and authorities will have precious information for them to make good health programs and to assess the social determinants of health.
Here you enter the person date of Social Security Number, birth, citizenship, sex, profession, the Domiciliary Unit, education level and marital status, among others. Other models (eg, patient) modules (eg, socioeconomics) will make extensive use of these field. Most of the fields are self-explanatory and don't need to get into details. We'll just make some tips about some of them.
• PUID : This is the Person Unique Identifier Number or equivalent issue by a specific country of region. It can be empty, but once is entered, is unique to the person. The PUID is a key identifier of the individual. If there is a person that does not have a local PUID, set the Alternative ID checkbox and enter the information there.
• Alternative IDs : When you enable this checkbox, you will be able to enter new IDs, such as Passports, other countries SSNs, etc... The person can have multiple IDs, and they should be registered whenever possible. For example, it will facilitate contacting this person if she or he is from another country.For clarity sake, the alternative IDs section is not shown unless the checkbox is set.
• Unidentified : Check this box if the person has no ID at the moment of registration. This can be the case of people that is brought to the health center in an accident settings. Once we gather the information at a later time, we unset the checkbox and enter the ID.
• Domiciliary Unit : This is a relational field that points to the place where the person lives. This is the main person address and should not be confused with the addresses of their relatives acquaintances that we will describe next.
10.3. YOUR FIRST INDIVIDUAL IN GNU HEALTH 25
Person demographics in GNU Health
10.3.2
Contact Information
GNU Health person contact information
Click on the next tab (“General”) to enter the information this person contact information. The address can be associated to a person or an institution. For example, we are showing the address of “Caro Forte”, she is Ana Betz Kenpo Karate teacher, with the address of the Kenpo Karate school. Since the contact is associated to a physical person (relational field), you could easily get her teacher information opening the resource. This section also contains the contact mechanisms of the person, such as email or phone number.
Chapter 11
Families
11.1 The Family Concept in GNU Health
Since GNU Health 2.0, the family object is a model that holds all the individuals that compose a family, from the legal and/or genetic point of view. The family members don't necessarily share the sameDomiciliary Unit.
A person can be part of several families at the same time. Consider the following situation: • Peter Stone is the son of Mattew Stone and Rosanna Pellegrino.
• Peter marries Sandra Miller and has two children with her.
• After being divorced, Peter marries Lucia Martinez, and they have another child. So Peter Stone would be:
• a son in the Stone-Pellegrino family • the husband in the Stone-Miller familiy • the husband in the Stone-Martinez familiy
The family model should only be used for one couple and their children, since things can become confusing otherwise. However, the system does not prevent you from entering families with more than two generations.
11.2 Managing Families
Families are managed in the GNU Health → Demographics → Families section.
If you are creating a family, the first thing to do is to assign it a unique family name. In our demo database we use a combination of the two lastnames of husband and wife (e.g. “Zenon-Betz” for the familiy of John Zenon and Ana Betz). While this should work fine most of the time, you will run into problems when you have several families with the same combinations of lastnames. In this situation, adding the firstnames could help to make the familiy name unique (e.g. “Zenon-Betz, John & Ana”).
Below the family name you will find a list of the family members, each consisting of the following fields: • Party: Link to a person (or a Party record whith the Person flag set, to be technically correct).
• Role: The role of this person within the familiy (e.g. “Mother”, “Son”). Please note that this is a simple text field where you can enter whatever you like. There are no predefined roles, and there is no validation (like a to make sure that a mother is female or that a son is younger than its father).
11.3. SEARCHING FAMILY MEMBERS 27
GNU Health family
11.3 Searching Family Members
In the GNU Health → Demographics → Family Members section you can find a list of all family members. This list is read-only, but you can use it to search family members by family name, party (person) or role.
Chapter 12
Health Professionals
12.1 The Health Professional Concept
The health professional is one of GNU Health’s key components: It’s used in appointments, patient evaluation, surg-eries, lab tests, etc. This is why it is important to have them defined in your system before hand.
The health professional is a general concept: It covers physicians, nurses, biochemists, psychologists, and any other occupation related to health sciences.
12.2 Creating and Editing Health Professionals
Adding a new health professional
To define or edit a new Health Professional, follow this path: Health → Configuration → Health Professionals → Health Professionals
The Main steps involved in defining a Health Professional are: 1. Select (or create) the related party
12.2. CREATING AND EDITING HEALTH PROFESSIONALS 29
2. Associate an internal user (login user) to the party 3. Define the health professional list of specialties 4. Set the default or main specialty
12.2.1
Party associated to a Health Professional
The health professional is a party with specific attributes, but is always a party. This abstract concept of party allow us to be different entities at the same time. For example, a health professional can also be a patient; both entities sharing the property of being a person. The party concept provides versatility and simplicity to GNU Health.
Party associated to a Health Professional
When you create the associated party from the Health Professional form, the Person and Health professional attributes will be automatically set. At this point, you need to enter the Health Professional demographics, in the same way as you have done when creating an individual. You might want to refresh the idea by glancing over theIndividuals
section.
12.2.2
The Internal User field
The Individual, when assigned the property of being a Health Professional, it has an extra - and required - field. The “Internal User” field. This internal user is the user that the individual types in then logging into GNU Health. That user allows to digitally sign documents, and to audit their actions.
Once you are done with the party, save the party record ( Ctrl + S ).
12.2.3
Health Professional specific fields
A health professional might have more than one specialty. In the Health Professional view, you can add all the specialties related to this particular professional. Once you are done, save the record ( Ctrl + S ). This is important
30 CHAPTER 12. HEALTH PROFESSIONALS
Associating the login user to a health professonal in GNU Health
Assigning a Main Specialty to the health professional from the list of this professional.
so the system links the party with the health professional record. Finally, add the information related to the the professional:
• Institution • Practitioner ID • Main Specialty • Extra information
12.2. CREATING AND EDITING HEALTH PROFESSIONALS 31
Although these fields are not formally required, they are very important and should be entered in the system. Each health professional must have these fields filled in whenever possible. For instance, the Main Specialty field will be used as a default value whenever the doctor is assigned an appointment, or when creating a new evaluation.
Chapter 13
Medicaments
Chapter 14
Prescriptions
14.1 About Prescriptions
Prescriptons can be found in the Health → Prescriptions section of GNU Health. However, since in most cases you only need to see the prescriptions of a specific patient, the recommended way is to open a Patient record and to switch to Prescriptions using the Relate button.
14.2 Information Stored in Prescriptions
Each Prescriptions record stores some general information: • Patient: Link to a patient (mandatory)
• Prescription ID • Prescription Date
• Prescribed by: Link to a health professional
• Pharmacy: Link to a pharmacy (i.e. a Party record with the Pharmacy flag set) • Pregnancy Warning
• Prescription Verified
The information about the medicaments can be found in the Presciption Lines section. Each Prescription Line consists of the following fields:
• Medicament: Link to amedicament
• Indication: Link to a Pathology Info record • Allow Substitution
• Form: Link to a Drug Form record
• Administration Route: Link to another Drug Form record • Start: Date and time
• End: Date and time • Dose
34 CHAPTER 14. PRESCRIPTIONS
• Dose Unit: Select an existing dose unit or create a new one • Times
• Frequency • Admin Hours • Frequency
• Unit: Choose from “Seconds”, “Minutes”, “Hours”, “Days”, “Weeks”, or “When required” • PRN: Short for pro re nata (= use it as needed)
• Treatment Duration
• Treatment Period: Choose from “Minutes”, “Hours”, “Days”, “Weeks”, “Months”, “Years”, or “Indefinite” • Review: Date and time
• Units • Refills # • Comment
Note: Only a fraction of these fields are visible in the list view, so make sure to open a Prescription Line in the form you to have access to all fields.
14.3 Prescription stock
Prescriptions can be tracked and inventoried by means ofstock management.
To quickly create a new stock move, right-click the prescription > Actions > Create Prescription Stock Move. To view previous stock moves, right click the prescription > Relate > Stock Moves [readonly].
Chapter 15
Vital Records
15.1 About Vital Records
Since version 2.8, GNU Health also serves as aVital Record System, allowing to create and sign birth and death certificates.
15.2 Birth Certificates
The person birth certificate is part of the GNU Health Vital Record System. It links the person to an official document with the information used in most countries. The information about the date of birth is taken from the person. In addition, if your institution has theGNU Health pediatricsmodule installed, the date of birth is automatically taken from the neonatology department.
Link to the related Birth Certificate of the person.
Alternatively, birth certificates can be managed via Health → Demographics → Birth certificates section. A birth certificate stores the following information:
• Person: The name of the newborn (link to a person record) • Date of Birth : By default, taken from the person (party) model. • Mother and Father (links to person records)
• Institution: The health institution where the birth took place (or the health institution that certifies a delivery at home)
• Code
• Country and Subdivision: These fields will be automatically filled as default values, with the the country and subdivision (such as province) of the institution.
• Observations
If you create a birth certificate record it will have the Draft state by default. You can switch to the Signed state by clicking the Sign button. You will be prompted to confirm that you want to sign the birth certificate; please note that signing a birth certificate can not be undone. Signing a birth certificate will add the name of the certifier (the health professional) plus date and time of the signing process.
36 CHAPTER 15. VITAL RECORDS
Birth certificate in Draft state
Confirmation dialog when signing
15.3 Death Certificates
The death certificate is a key document, since it has legal, administrative, demographic and epidemiological signifi-cance.
Death certificates work very much the same way like birth certificates, but they store more information about causes and circumstances of death. The best way to access a person death certificate is by using the related action from the Party model (refer to the birth certificate section). Alternatively, the can be accessed via Health → Demographics → Birth certificates section.
15.3. DEATH CERTIFICATES 37
Birth certificate in Signed state
Vital Records on GNU Health : Death Certificate
Main section:
• Person: The name of the dead person (link to a person record) • Date: Date of Death, including hour and minute.
Place section:
• Place: Details about where the person died (at home, at work, in a public place, in a health institution) • Details about the place
38 CHAPTER 15. VITAL RECORDS
GNU Health : Signing a death certificate using digital signatures, with the Health cryptographic module - GNU Privacy Guard (GPG) plugin
• DU: The exact building/address (link to adomiciliary unitrecord)
• Institution: The health institution where the person died (or the health institution that certifies a death which occurred at home, at work, or in a public place)
• Op. Sector: Operational Sector where the death occurred.
• Country and Subdivision, such as province. These two fields are automatically filled with the address information from the health institution.
Cause section:
• Cause: The immediate cause of death (link to a Disease record)
• Underlying conditions: Medical conditions that lead to death, in chronological order. Other section:
• Type of death: Choose between “Natural”, “Suicide”, “Homicide”, “Undetermined”, or “Pending Investigation” • Autopsy: Check if an autopsy has been performed
• Code: Unique identifier to the certificate. The format / nomenclature is country-dependent. • Observations
If you create a death certificate record it will have the Draft state by default. You can switch to the Signed state by clicking the Sign button. You will be prompted to confirm that you want to sign the death certificate; please note that signing a death certificate can not be undone. Signing a death certificate will add the name of the certifier (the health professional) plus date and time of the signing process.
15.4. DIGITAL SIGNATURES 39
15.4 Digital Signatures
It is highly recommended that you use digital signatures to sign the death certificate. The GNU Health Cryptography module health_crypto has the functionality to verify any change to the document. It also allows you to use your private key to sign the document, giving it legal value in many countries. Once signed, the document can be verify against the person who ultimately signed the certificate.
Chapter 16
Immunizations
GNU Health includes immunization functionality in the core module. This includes immunization schedules per country and year, the vaccination process, and the person immunization history and status report, to name the main aspects.
16.1 The Vaccine
Vaccines from the WHO list of essential medicines
In GNU Health, vaccines are part of the medicament model, those that have set the vaccine attribute. GNU Health includes as default the vaccines that are part of the WHO essential list of medicines module, but you can set up your own set.
16.2. THE IMMUNIZATION SCHEDULE 41
16.2 The Immunization Schedule
Health → Configuration → Immunization Schedule
Immunization schedule sample
After you have the list of vaccines, you can create different immunization schedules. Each immunization schedule has the following fields:
• Code: Unique identifier for the schedule
• Country: The name of the country for this schedule • Year: The year of this immunization schedule
• Active: This field indicates whether this particular schedule is on use. Among other things, it’s taken into account when checking the immunization status of the person.
• Description: Short description of the schedule
• Vaccines: This widget lists all the vaccines on the schedule, and the main attributes. The details for this model will be explained in the next section.
16.2.1
Immunization Schedule Line
As described above, each immunization schedule is composed of vaccines, which their own peculiarities. For each vaccine, the following attributes apply:
• Vaccine: The name of the vaccine
• Scope: Recommendation status level . It can be systematic, recommended or limited to risk groups • Remarks: Additional information and for this vaccine
• Dose: Dose or booster number
• Age: Age of the person when should be applied • Time unit: Days, weeks, months or years
