Written by Technical Team | Last updated 16.07.2026 | 25 minute read
Maternity care is delivered across a complex network of hospital departments, community services, diagnostic teams, primrmation may be created by midwives, obstetricians, sonographers, anaesthetists, neonatal teams, laboratory services and the woman herself. A maternity information system, like K2 Athena or System C BadgerNet brings much of this information together, but it rarely operates in isolation.
Digital health solutions increasingly need to exchange data with maternity information systems to support remote monitoring, personalised education, clinical decision support, digital maternity records, appointment management, population health analysis and more coordinated care. Without integration, these products risk creating a parallel information environment in which clinicians must search multiple applications, copy information manually or make decisions without seeing the complete clinical picture.
Integrating a digital health solution with a maternity information system is therefore more than a technical exercise. The integration must fit established clinical workflows, preserve the meaning and provenance of maternity information, manage patient and pregnancy identities accurately, protect sensitive data and remain dependable during safety-critical episodes of care. It must also work within the technical and governance environment of each NHS organisation in which it is deployed.
The strongest integration programmes begin by defining the clinical purpose of the connection before selecting an API, messaging standard or integration platform. Technology should follow the workflow, rather than forcing the workflow to conform to the technology. This article explains how digital health suppliers and NHS organisations can approach secondary care MIS integration systematically, from discovery and architecture through to assurance, testing, deployment and ongoing support.
Key takeaway: Successful maternity information system integration starts with a clearly defined clinical workflow, not a preferred API or interoperability standard. Digital health suppliers and NHS Trusts should align patient identity, pregnancy context, data standards, clinical safety, information governance and operational support before connecting remote monitoring, digital maternity records or other healthcare technology to an NHS maternity information system.
An integration project can appear straightforward when described as a list of data fields: send patient demographics, retrieve appointments, write observations and receive discharge information. In practice, each of those exchanges sits within a clinical pathway containing decisions, dependencies, exceptions and local working practices. Before designing an interface, the project team must understand how maternity care is actually delivered.
The maternity journey may begin with a referral or self-referral and continue through booking, antenatal assessment, screening, diagnostic investigations, birth planning, intrapartum care and postnatal follow-up. Some women follow a relatively standard pathway, while others require specialist input for conditions such as diabetes, hypertension, multiple pregnancy, fetal growth concerns or previous obstetric complications. Care may move between community and hospital settings several times, sometimes across organisational boundaries.
A digital health product should therefore be defined in terms of the clinical tasks it supports. A remote monitoring solution, for example, may collect blood pressure readings and symptoms at home. The important question is not merely whether those readings can be transmitted to the maternity information system. The project must determine who reviews them, how quickly they must be available, what happens when a reading is outside the expected range, whether an acknowledgement must be returned and how the reviewing clinician records the resulting decision.
The same principle applies to patient-facing maternity applications. Giving a woman access to appointments, care plans or personalised information may require the application to understand gestational age, pregnancy status, booking details, clinical risk factors and changes to the care pathway. Data cannot simply be extracted and displayed without rules governing timeliness, interpretation and suitability for patient access. Some information may need clinical review before publication, while other information may need explanatory content to prevent misunderstanding.
Discovery should bring together clinical, operational and technical stakeholders. Midwives and obstetricians can explain how care is delivered and where incomplete information creates risk. Digital midwives can help translate between clinical practice and system configuration. Trust integration teams can identify available interfaces, infrastructure constraints and message flows. Information governance, cyber security and clinical safety specialists can expose requirements that might otherwise emerge late in delivery. The maternity system supplier should be engaged early because the theoretically preferred integration route may not be available in every deployment or product version.
A useful discovery process should establish:
This work should produce a set of end-to-end data-flow and workflow scenarios rather than a generic catalogue of fields. Each scenario should describe what initiates the exchange, which systems participate, what information passes between them, how success is confirmed and what happens when the process does not complete normally.
Consider the difference between “send blood pressure observations” and a complete workflow scenario. In the complete scenario, a woman records a blood pressure reading in a digital application. The application validates the format, associates the reading with the correct patient and active pregnancy, records the device and timestamp, and transmits it securely. The receiving environment validates the message, writes the observation to the correct location and confirms acceptance. If the value breaches a clinically defined threshold, the appropriate maternity team is alerted through an agreed operational process. If transmission fails, the application informs the user appropriately and attempts recovery without creating duplicates.
Mapping workflows at this level reveals requirements that are easily missed in a purely technical specification. These may include whether clinicians need to distinguish patient-entered data from professionally recorded measurements, whether the original device reading must be retained, how late-arriving information is presented and whether an observation can be amended after clinical review.
Discovery should also define project boundaries. It may be tempting to make the first integration support every maternity pathway and every possible data item, but this increases complexity and makes assurance difficult. A focused initial release based on a valuable, measurable workflow often creates a stronger foundation. Later phases can expand the data scope once patient matching, mappings, monitoring and operational responsibilities have been proven in a live environment.
Once the clinical workflows are understood, the project can select an appropriate integration architecture. There is no single technical pattern that works for every maternity information system or NHS Trust. The design may need to combine modern APIs with established messaging standards, vendor-specific interfaces and local integration infrastructure.
FHIR is frequently associated with modern healthcare interoperability because it provides structured resources and web-based interaction patterns. Where a suitable FHIR interface exists, it can support clear, reusable representations of patients, appointments, encounters, observations, conditions, procedures and other clinical information. FHIR can also make it easier to expose narrowly defined services rather than broad database extracts.
However, using FHIR does not automatically make an integration interoperable. Two systems can exchange technically valid FHIR resources while interpreting the data differently. Profiles, extensions, terminology bindings, cardinality rules and implementation guidance are needed to constrain the standard for a specific use case. The project must establish precisely which version and profiles are supported, which elements are mandatory and how maternity-specific concepts are represented.
Many secondary care environments also depend heavily on HL7 version 2 messaging. Admissions, discharges and transfers may be distributed through ADT messages, while observations and results may be carried through other established message types. HL7 v2 remains valuable because it is widely supported and well understood by hospital integration teams. Nevertheless, local variations are common. Segment usage, optional fields, code sets and event handling can differ between organisations, even where the same general message type is used.
A robust secondary care MIS integration strategy should therefore allow FHIR, HL7 v2 and proprietary APIs to coexist. The objective is not to select the newest technology for its own sake, but to use the most reliable interface available for each workflow. An integration might use an HL7 ADT feed for real-time demographic and encounter events, a vendor API for maternity-specific information and a FHIR service for exchanging structured observations.
Integration engines often provide the controlled boundary between the Trust environment and the digital health solution. They can receive messages from source systems, transform data into a canonical model, validate required fields, route information to the appropriate destination and retain operational audit records. Using an integration engine can also reduce direct dependencies between an external product and the maternity information system.
A canonical data model can be especially useful when a solution must connect to multiple maternity platforms or multiple Trust configurations. Instead of allowing product logic to become tied to each supplier’s interface, vendor-specific data can be transformed into a consistent internal representation. This does not remove the need for local mapping, but it isolates many differences at the integration boundary.
The canonical model should not be designed as an indiscriminate copy of every available maternity field. It should represent the clinically meaningful concepts required by the supported workflows, including their identifiers, timestamps, status, provenance and relationships. A compact, well-governed model is often more sustainable than a vast schema that attempts to anticipate every future requirement.
The architecture should explicitly define the direction and frequency of each exchange. Common patterns include synchronous API requests, asynchronous event messages, subscriptions, scheduled batch transfers and combinations of these approaches. A synchronous API may be suitable when a clinician requests current information and needs an immediate response. Event-driven messaging may be more appropriate when the digital solution must react to changes such as a new registration, appointment update or pregnancy outcome.
Batch transfers can remain appropriate for analytics, migration or lower-priority reporting, but they are less suitable for information that influences immediate clinical action. The project must avoid describing data as “real time” without defining a measurable service expectation. A five-second delay, five-minute delay and overnight update may all be described casually as timely, yet they have very different clinical implications.
Connectivity must also be addressed early. Depending on the systems involved, the integration may operate through HSCN, a Trust-managed private connection, a secure internet-facing API, a virtual private network or a hybrid architecture. Cloud-hosted products may require a controlled gateway or connector within the Trust environment. The design should minimise inbound access, use strong encryption and avoid unnecessary exposure of internal systems.
Authentication confirms the identity of the calling system or user, while authorisation determines what that identity may do. These concerns should be designed separately. Machine-to-machine exchanges may use mutual TLS, signed tokens or managed client credentials. User-context integrations may require single sign-on, role-based access controls and a reliable association between the user’s organisational role and the permissions applied within the receiving system.
Security controls must be proportional to the sensitivity of maternity information. Pregnancy records can contain safeguarding information, mental health details, substance-use history, genetic or screening information, domestic abuse disclosures and information concerning babies or family members. Access should be limited to what is required for the stated purpose, and audit records should make it possible to determine who or what accessed information, when it was accessed and which action was performed.
Resilience is equally important. The architecture should define timeouts, retry rules, message queues, dead-letter handling and reconciliation processes. Automated retries must be idempotent so that repeating a request does not create duplicate observations, appointments or tasks. Where the receiving system is unavailable, messages may need to be queued securely until service is restored.
The digital solution should degrade safely. If live maternity information cannot be retrieved, the interface must not silently present old data as current. If a patient-generated observation cannot be delivered, the user should receive clear guidance that reflects the clinical importance of the information. The system must never imply that a maternity team has received or reviewed data when only a technical transmission attempt has occurred.
The most difficult part of maternity information system integration is often not transporting data but preserving its meaning. Maternity records contain concepts that are highly contextual. A value may relate to the woman, fetus or baby; to the current pregnancy or a previous pregnancy; to an antenatal appointment, birth episode or postnatal assessment. Removing that context can turn correct data into misleading information.
The Digital Maternity Record Standard provides an important foundation for consistent maternity information. It describes the expected structure and format of a maternity record and supports more consistent capture and sharing across systems. Integration projects should use the standard as a semantic reference even where the technical interface is not itself a direct implementation of the standard.
A data-mapping exercise should start with clinical concepts rather than database columns. For every data item, the project should determine its definition, permitted values, units, status, timestamp, source and relationship to other information. A field called “delivery date”, for example, may appear straightforward but could represent the actual time of birth, a planned delivery date, the date entered into the system or a summary value derived from another record. Field names alone are not sufficient evidence of meaning.
Mappings should identify whether a value is coded, free text, numeric, Boolean or composite. Where coded data is exchanged, national terminologies such as SNOMED CT should be used where appropriate and supported. Local codes may still be present within source systems, but they should be documented and mapped explicitly rather than passed downstream without interpretation.
Units require particular care. A clinically correct numeric value can become dangerous when its unit is omitted, assumed or transformed incorrectly. Observations should carry explicit units using a consistent notation, and conversions should be controlled, tested and auditable. The original value and unit may need to be retained alongside any normalised representation.
Clinical status must also survive the integration. A planned procedure is not the same as a completed procedure. A preliminary result is not equivalent to a final result. An appointment that has been cancelled should not remain visible as an upcoming attendance. Systems should exchange status changes and amendments, not merely the latest values available at the time of an extract.
Provenance allows users and systems to understand where information originated. For patient-generated health data, provenance may include the patient, application, connected device, time of measurement and time of receipt. For clinician-recorded data, it may include the author, organisation and source maternity system. Preserving provenance helps clinicians judge how information should be interpreted and supports investigation when discrepancies arise.
Patient matching is another central risk. The digital solution must associate data with the correct person, while also linking it to the correct pregnancy episode. NHS number is a valuable national identifier, but it should be used within a controlled matching process rather than treated as infallible. Demographic information may be incomplete, entered incorrectly or temporarily unavailable. Babies may initially have limited identifying information, and demographic changes can occur during the care pathway.
The matching strategy should define which identifiers are authoritative, what combinations are accepted and how uncertain matches are handled. It should distinguish between identity verification, demographic matching and pregnancy-episode linkage. A system should not automatically attach clinical information where the match is ambiguous merely because several demographic fields appear similar.
Pregnancy identity deserves specific attention. A woman may have multiple pregnancy records, and some systems represent pregnancy, fetus, birth and baby records as related but distinct entities. The integration must ensure that information is not associated with a historical pregnancy or the wrong fetus in a multiple pregnancy. Stable source identifiers should be retained wherever possible rather than recreating relationships through dates or assumptions.
Master data and reference data must also be governed. Organisation identifiers, location codes, clinician identifiers, appointment types, care settings and outcome values may differ across deployments. Some mappings can be standardised nationally, while others will remain local. The project should maintain a version-controlled mapping specification showing the source value, target value, transformation rule, owner and effective date.
Validation should occur at multiple layers:
Not every validation failure should produce the same result. A malformed identifier may require the message to be rejected. A missing optional field may justify a warning. A temporary inability to locate a related pregnancy record may require the message to be held for reprocessing. The handling rule should reflect the potential clinical and operational consequences.
Free text creates additional complexity. Narrative information may contain valuable nuance that cannot be represented fully through coded fields, but it may also contain information that should not be displayed in every context. The integration should define whether free text is required, how formatting is preserved, whether content is searchable and which user groups may view it. Free text should not be used as a substitute for structured information needed by automated workflows.
The final mapping should be reviewed by clinicians who understand the maternity pathway, not solely by technical teams. A mapping can be syntactically perfect while remaining clinically wrong. Clinical walkthroughs using realistic cases are one of the most effective ways to reveal incorrect assumptions about status, timing, ownership and meaning.
Maternity integration is safety-critical because delayed, missing, duplicated or incorrectly attributed information can influence clinical decisions. Safety must therefore be part of the design process from the beginning rather than a documentation exercise performed immediately before deployment.
The digital health supplier is generally responsible for applying clinical risk management to the development and maintenance of its product. The deploying healthcare organisation is responsible for managing the risks introduced through local configuration, implementation, use and eventual decommissioning. These responsibilities are closely connected. The supplier’s safety evidence should inform the Trust’s deployment assessment, while local workflow decisions may introduce hazards that the supplier could not evaluate in isolation.
A Clinical Safety Officer should be involved early enough to influence requirements and architecture. The clinical risk management process should identify potential hazards, estimate their causes and consequences, define controls and record evidence that those controls have been implemented. The hazard log should evolve as new information emerges during design, testing, deployment and live operation.
Integration-specific hazards frequently arise at the boundaries between systems. Examples include data being attached to the wrong patient, an outdated result being presented as current, a message being accepted technically but not displayed to the intended user, duplicate events creating multiple clinical tasks, or a failed transmission not being visible to the person responsible for follow-up.
Risk controls should not depend entirely on the software. A complete control model may combine technical validation, user-interface design, operational procedures, training, monitoring and escalation. For example, an interface may validate the format of an incoming observation, display its provenance clearly, alert a maternity team when thresholds are breached and provide an operational dashboard showing unprocessed records.
Human factors are especially important. Alerts that are too frequent or poorly prioritised may be ignored. Information placed in an unfamiliar part of the maternity record may technically be available but remain practically invisible. A confirmation message may give false reassurance if users misunderstand it as evidence of clinical review. Safety assessment must examine how people interact with the integrated service in realistic conditions, including periods of high workload.
Information governance should be equally embedded. The project must establish a lawful basis for processing, identify the organisations acting as controllers or processors and define the purposes for which data is exchanged. Data flows should be reflected in contractual and governance documentation, and a Data Protection Impact Assessment should evaluate privacy risks arising from the integration.
Data minimisation is particularly relevant. An interface should not extract an entire maternity record when the digital solution requires only a small number of fields. Reducing the scope of data lowers privacy risk, simplifies mapping and makes it easier to explain the processing to users. It also reduces the impact of a security incident.
Retention rules should distinguish between operational messages, clinical records, audit data and troubleshooting information. Integration platforms frequently retain payloads for support purposes, but these copies can become an unmanaged secondary store of sensitive maternity information. Retention periods, access restrictions and deletion processes must be specified deliberately.
The NHS Digital Technology Assessment Criteria provides a common framework for evaluating digital health technologies across clinical safety, data protection, technical security, interoperability, usability and accessibility. Preparing for DTAC should be treated as part of product and integration design. Evidence is far stronger when it reflects established delivery practices than when it is assembled retrospectively.
Cyber security assurance should cover the complete service, including the digital product, integration components, cloud environment, Trust-side connectors and administrative interfaces. Threat modelling can identify risks such as stolen credentials, replayed messages, unauthorised access, data exfiltration, malicious payloads and compromise of the integration engine. Controls should include encryption, key management, least-privilege access, secure development practices, vulnerability management, penetration testing and incident response.
Accessibility must not be overlooked, particularly where the integration supports patient-facing maternity services. Digital exclusion can affect people through disability, language, financial constraints, limited connectivity or low confidence with technology. An integrated service should not create a pathway in which people who cannot use the digital product receive a lower standard of care. Alternative routes and reasonable adjustments should be built into the operating model.
The project should also assess whether the digital health solution is a medical device under applicable UK regulations. This depends on the intended purpose and functionality rather than the marketing description alone. Products that provide diagnostic, monitoring or treatment-related functionality may carry regulatory obligations in addition to NHS assurance requirements.
Assurance artefacts should form a coherent evidence set. Requirements should trace to design decisions, tests and risk controls. Architecture documentation should correspond with deployed infrastructure. The data-flow description used for information governance should match the actual integration. Clinical safety documents should reflect the final workflow, not an earlier prototype.
Integration testing must go beyond proving that one system can send a technically valid message to another. The purpose of testing is to demonstrate that information moves accurately, securely and predictably through the complete service, and that users can respond safely when normal or exceptional events occur.
A layered test strategy is usually most effective. Component tests can verify transformations and validation rules. Contract tests can confirm that both parties interpret an interface consistently. System integration testing can exercise the connected environments. User acceptance testing can determine whether the resulting workflow supports real clinical practice. Performance, resilience, security and clinical safety testing should be planned alongside functional testing rather than added at the end.
Test data must cover realistic maternity scenarios. Happy-path examples are necessary but insufficient. The team should test incomplete referrals, demographic amendments, multiple pregnancies, historical pregnancy records, cancelled appointments, corrected observations, late-arriving messages, duplicate transmissions and temporary system outages. Scenarios should include people with similar demographic details to test matching controls.
Multiple births and complex pathways are particularly valuable test cases because they expose assumptions hidden within simple data models. The project should verify that each fetus or baby remains associated with the correct records and that updates do not overwrite information belonging to another entity. It should also test transfers between locations, care teams and organisations where these are within scope.
Testing should verify where information appears in the receiving maternity information system, not merely whether it exists in a database or message log. Clinicians should confirm that the information is visible at the right point in their workflow, labelled appropriately and accompanied by the context required for interpretation.
Negative testing is essential. The team should deliberately send malformed messages, invalid codes, unexpected units, unknown identifiers and events in the wrong order. The objective is to demonstrate that bad data fails safely and visibly. Rejected or quarantined messages should be available to authorised support staff with enough diagnostic information to resolve the issue without exposing unnecessary patient data.
Resilience testing should simulate unavailable endpoints, network interruption, delayed acknowledgements and partial processing. Queued information should be recovered in the correct order where order matters. Retries should not generate duplicates. Operational teams should understand how to identify the backlog, how long recovery might take and when clinical services must use an alternative process.
Performance requirements should be based on realistic peaks rather than average daily volume alone. Maternity services may experience concentrated activity, and other hospital systems sharing the integration infrastructure may generate substantial load. Testing should measure throughput, response time, queue growth and recovery after an outage.
Before go-live, the project should complete a readiness review covering technical, clinical and operational responsibilities. Monitoring should be active, support contacts confirmed, runbooks approved and rollback options understood. Users should know when the integrated service becomes authoritative and whether any temporary parallel process is required.
A phased deployment can reduce risk. The integration may begin with a limited clinical team, site or workflow before expanding. Early deployment should include enhanced monitoring and rapid access to clinical, product and integration specialists. The purpose of this period is not simply to fix software defects but to identify differences between the designed process and real-world practice.
Live monitoring should measure more than server availability. A technically healthy interface can still fail to deliver useful information. Operational monitoring should include message volumes, processing latency, rejection rates, queue depth, unmatched patients, duplicate events and reconciliation differences. Trends can reveal gradual degradation that a simple uptime check would miss.
Reconciliation is particularly important when the data has clinical significance. The project should be able to compare what the source attempted to send with what the destination accepted and stored. Reconciliation rules may operate automatically, with exceptions routed to a support team. The process should avoid relying on clinicians to discover missing data during care.
Support responsibilities must be unambiguous. When an observation is not visible, the issue could sit within the patient application, integration platform, Trust network, maternity information system or local configuration. A shared support model should define the initial point of contact, diagnostic information available to each team and escalation routes between organisations.
Changes must be managed as carefully as the original implementation. Maternity information systems, integration engines, terminology releases, security requirements and digital products all evolve. A seemingly minor field change can affect mappings, validation and clinical display. Interface versioning and change notification should therefore be agreed contractually and operationally.
Regression testing should focus on clinically important workflows and known hazards. Automated tests can provide rapid feedback when mappings or interface components change, but they should be complemented by clinical review where the presentation or interpretation of information may be affected.
The hazard log, safety case, data-flow records and support documentation should remain live artefacts. Incidents, near misses and recurring message failures should feed into product improvement and clinical risk management. A safe integration is not one that has never recorded a problem; it is one that makes problems visible, responds effectively and learns from them.
Successful maternity information system integration ultimately depends on sustained partnership. Digital health suppliers, maternity teams, Trust IT departments, clinical safety specialists and system vendors must continue to work together after launch. No single organisation controls the entire pathway or technical environment.
When delivered well, integration allows the digital health solution to become part of the maternity service rather than another disconnected application. Clinicians gain timely information within familiar workflows, women experience more coordinated digital services and organisations reduce the operational burden of manual data transfer. The result is not merely a functioning interface, but a dependable clinical capability that supports safer, more joined-up maternity care.
Organisations planning secondary care MIS integration should begin with a focused clinical use case, engage the maternity system supplier and local Trust teams early, and develop safety, governance and operational requirements alongside the technical architecture. This integrated approach creates the strongest foundation for connecting digital health solutions with maternity information systems reliably and at scale.
Can a digital maternity solution be piloted before full MIS integration?
Yes, but the pilot should have a clearly defined process for transferring clinically important information into the maternity record. NHS maternity technology pilots should also measure the additional workload created by manual data entry, as a successful standalone pilot may require further redesign before it can operate safely at scale.
How much does maternity information system integration cost?
The cost of NHS maternity system integration depends on the interfaces supplied by the MIS vendor, Trust integration charges, hosting arrangements, testing requirements and ongoing support fees. Buyers should establish whether API access, interface development, test environments, supplier consultancy and future upgrades are included in the commercial agreement.
What happens to an integration when an NHS Trust replaces its maternity information system?
An MIS replacement will usually require interfaces, mappings and workflow rules to be reassessed against the new platform. Contracts should therefore cover data portability, access to interface documentation, migration support and supplier exit arrangements so the digital maternity service is not unnecessarily tied to one system vendor.
Can integrated maternity data be used for NHS reporting or research?
Potentially, but data collected for direct maternity care cannot automatically be reused for every reporting, service evaluation or research purpose. Organisations should define each secondary use separately and confirm the relevant governance, data-quality and access requirements, including whether information must be transformed for the Maternity Services Data Set or de-identified before analysis.
Is your team looking for help with Maternity Information Systems integration? Click the button below.
Get in touch