Challenges and solutions to identifying pregnancy codes in Electronic Health Records (EHRs)
- Posted:
- Written by:
-
- Helen Curtis, Vicki Palin, Paolo Mazzone, Victoria Burns, Rose Higgins, Em Prestige
- Categories:
Identifying pregnancy in electronic healthcare records (EHRs) can be particularly challenging for researchers. As pregnancy information is spread across GP records, maternity services, and hospital data — with variation in how and when events were recorded — it is often difficult to determine when a pregnancy started, whether it is ongoing, and what the outcome was.
This blog post outlines some of the key challenges in identifying pregnancy codes in EHRs and explains how algorithmic approaches can help researchers make sense of incomplete or conflicting health records.
Challenges to identifying pregnancy codes in Electronic Health Records (EHRs)
Multiple care settings
Pregnancy care is distributed across multiple care settings, which means no single record source reliably captures the full pregnancy journey or outcome. Pregnancy care is delivered mainly within maternity services, such as community midwives or midwifery teams, and maternity units within hospitals. Not all information about pregnancy and its outcome is recorded in GP records, and births do not all occur in hospitals. For this reason, GP records may also show pregnancy at inconsistent points because patients often book-in directly through their midwifery services rather than through their GP practice.
Although pregnancies have a well-defined maximum length, their actual length can vary substantially, ranging from early losses and terminations to full term pregnancies. Patients may also have multiple pregnancies close together which may be hard to separate in digital records.
For example, the beginning of pregnancy may be indicated via a “last menstrual period” (LMP) date, but this code could also be used for reasons other than pregnancy, such as irregular periods or cervical screening. If LMP is not recorded, an end of pregnancy record (e.g. delivery/stillbirth/miscarriage) alone cannot help us reliably or accurately determine the start date of pregnancy - or at what point the patient found out they were pregnant.
Variable outcomes
Pregnancy has multiple outcomes including livebirth, stillbirth, miscarriage and termination, so several possible codes can be used to indicate outcome and aftercare. Some patients have conflicting outcome codes and/or dates for the same pregnancy. For example, patients might not report early losses or pregnancy terminations to their GP, so if a GP records pregnancy prior to one of these events, it might have no discoverable end date or outcome in the patient’s record.
Also, the set of codes for termination of pregnancy are not available in OpenSAFELY, as they are subject to access restrictions in some settings. This adds uncertainty to the outcome type for pregnancies of a seemingly short time-frame, particularly for surveilling the latest data and determining if the pregnancy is still ongoing.
How algorithms help us identify pregnancy codes in Electronic Health Records (EHRs)
An ‘algorithmic’ approach – a process using multiple sources to triangulate information – can help us identify the length, event(s), and outcome of pregnancy in EHRs. For example, researchers can combine diagnosis and procedure codes from the hospital record and clinical codes from the GP record to analyse birth methods. This approach is effective at filling in missing information gaps, but requires a set of rules to manage conflicting information when that arises.
For a comprehensive overview of how pregnancies can be identified in research, see Mazzone et al’s scoping review. There is ongoing work by the same group to develop a reusable algorithm for OpenSAFELY that comprehensively identifies pregnancies and outcomes - see OpenPREGnosis.
Until this is available, researchers need to develop their own algorithms to study pregnancy and its outcomes, or to take into account pregnancy periods for other reasons. To learn more about one approach we took, and the data anomalies we encountered, read our next blog post.