Written by Technical Team | Last updated 02.08.2025 | 9 minute read
Integrating with GP Connect is one of the most important steps in enabling health and care systems across the NHS to access patient records in a consistent, secure, and clinically safe way. Among the various capabilities of GP Connect, the “Parameters” POST operation for Access Record Structured stands out as a key mechanism for retrieving a patient’s coded clinical information. This article provides an in‑depth exploration of how the operation works, the challenges involved in implementing it, and the benefits it can bring when applied effectively in real‑world health technology solutions.
The GP Connect initiative was introduced to solve a long‑standing problem within the NHS: the lack of a reliable, standardised way for different organisations and systems to view up‑to‑date patient records held in general practice. Historically, GP data was siloed within practice systems, making it difficult for clinicians in secondary care, urgent care, community services, or social care to access crucial details such as allergies, current medication, or recent consultations.
The Access Record Structured capability was designed to address this. Instead of manually requesting copies of patient records or relying on incomplete summaries, authorised systems can now retrieve structured, coded data directly from the GP practice system in real time. The Parameters POST operation is central to this process. Rather than requiring multiple queries for different categories of data, it allows a consumer system to send one request containing a FHIR Parameters resource that specifies exactly what is required. The provider system then returns a single, cohesive bundle containing the requested data, ensuring integrity, auditability, and clinical safety.
The approach is designed not just to provide efficiency but also to support direct care. Every request is fully traceable, every response is structured and validated against the GP Connect profiles, and the scope of the information retrieved is carefully controlled by the parameters specified. This design reduces the risk of overwhelming clinicians with irrelevant data while ensuring that critical details are not overlooked.
To use the Parameters POST operation correctly, the request must be constructed with great care. The interaction relies on the Spine Secure Proxy (SSP), which sits between the consumer and provider systems to manage authentication, routing, and auditing. For this reason, the request headers play as crucial a role as the message body itself.
The headers must always include the appropriate FHIR content types to ensure that both systems interpret the message correctly. They must also contain fields that identify both the sending and receiving systems, such as the ASIDs of each party, and a unique trace identifier to ensure the transaction can be audited later. The inclusion of an interaction ID allows the SSP to validate that the request is a legitimate call for the Access Record Structured operation. Without these elements, the request will not even reach the provider system, making compliance non‑negotiable.
The Parameters body itself begins with the mandatory patient NHS number, expressed as an identifier with the standard NHS Number system URL. This ensures the provider system can unambiguously locate the correct patient record. After this, the request may include a series of optional elements specifying which clinical domains should be included in the response. For example, a system handling urgent care admissions might request medication, allergies, and consultations, while a community midwife’s system might additionally ask for immunisations and investigation results.
Each of these clinical domains is requested via a Boolean flag, with some offering additional nested elements to fine‑tune the scope. For instance, the medication section allows the consumer to decide whether to include prescription issues, and to restrict the response to medicines prescribed from a particular date onwards. Similarly, consultation data can be filtered by date period or by limiting the number of most recent consultations to return. These options give consumers the ability to balance completeness with performance and clinical relevance.
Although the concept of including different domains may seem straightforward, in practice each category of data presents unique challenges for both providers and consumers.
For allergies and intolerances, the key decision lies in whether to include resolved allergies. Some clinical scenarios demand a complete history, including issues that are no longer active, while others only need to focus on current risks. The consumer therefore specifies this through a nested Boolean. Providers are responsible for returning the data in line with the GP Connect profile, ensuring that the information is consistent and coded correctly, typically using SNOMED CT.
Medication data is one of the most complex areas. The provider must collate Medication, MedicationRequest, MedicationStatement, and List resources to give a full picture of the patient’s current and recent prescriptions. The consumer may restrict the data to a certain time frame, for example the past year, to avoid receiving unnecessarily large payloads. The decision to include prescription issue data is also important, as this can significantly increase the volume of information returned.
Consultations are another high‑value domain. These records may contain details of diagnoses, referrals, and care plans, but the volume can be considerable if not carefully filtered. By allowing the consumer to set a date range or to limit the number of most recent consultations, the operation prevents clinicians being overwhelmed with years of historical data when only recent interactions are relevant.
Problems, immunisations, investigations, referrals, diary entries, and uncategorised data all have their own nuances. Problems can be filtered by status to exclude resolved or inactive conditions, keeping the focus on the patient’s active health issues. Immunisation histories are often crucial for community care and travel health but may be lengthy for older patients. Investigations, such as pathology or imaging, must be handled carefully to ensure that key results are returned with the correct context. Referrals and diary entries may be essential for ongoing care coordination. Uncategorised data ensures that important information not yet mapped into specific domains is still retrievable, though consumers must be prepared to display this in a way that makes sense to clinicians.
The richness of these domains highlights why the Parameters POST operation is essential: it allows the consumer to specify exactly what is needed, reducing unnecessary data transfer and supporting safe, focused care.
Once the provider system receives a valid request, it constructs a FHIR Bundle in response. This bundle is returned as a single package, typically with a “searchset” type, and is validated against the GP Connect structured record bundle profile. For the consumer, the challenge is to parse this bundle correctly and present the information in a safe and meaningful way.
Every bundle will include a Patient resource to confirm the subject of the record, along with the Organisation resource representing the registered GP practice. Where available, it may also include Practitioner and PractitionerRole resources to identify the patient’s usual GP. From there, the bundle contains the requested clinical data, grouped into lists and linked to the relevant supporting resources.
Consumers must take care not to assume a fixed order for the entries in the bundle. Instead, each resource should be located by following the references included within the bundle. For example, a Condition resource may reference the Practitioner who recorded it, and a MedicationRequest may reference the Medication resource defining the drug. Parsing by reference rather than order ensures that the consumer can handle bundles from different providers consistently, even if the order of resources varies.
Validation is another critical step. The consumer should check that the bundle conforms to the expected profile, verify that all required metadata is present, and confirm that any requested domains have been included. Empty domains must be handled gracefully, with clear messages to the user that no data was available, rather than implying an error.
Security labels within the resources may indicate that some items are not to be disclosed to patients, even if the consumer system is patient‑facing. These labels must be respected to maintain compliance with information governance. Equally, error handling is essential. The provider may return errors such as patient not found, access denied, or invalid parameter. Consumers must be ready to interpret these errors correctly and provide meaningful feedback to users without exposing unnecessary technical detail.
Successfully implementing the Parameters POST operation requires more than simply meeting the technical specification. It also demands attention to performance, usability, clinical safety, and long‑term maintainability.
From a performance perspective, the key is to request only what is necessary. Although it is technically possible to request every domain for every patient, this can lead to very large payloads, slower response times, and a poor user experience. Instead, consumer systems should tailor their requests to the specific needs of their users. For example, an emergency department system might focus on current medications, allergies, and problems, while a chronic disease management system might need a fuller history including consultations and investigations.
Clinical safety is equally important. Organisations implementing GP Connect must comply with clinical safety standards such as DCB0129 or DCB0160, depending on whether they are a system supplier or an NHS organisation. This involves identifying potential hazards, such as incorrect parsing of medication data or misinterpretation of coded information, and putting mitigations in place. Clinical safety officers play a vital role in overseeing this process and ensuring that systems are safe for use in direct care.
Error handling is another area that requires careful design. A patient not found error might arise because the patient is not registered at the provider practice, or because the record is marked as sensitive. The user interface should explain this clearly, without exposing raw error codes. Similarly, if the provider does not support a requested domain, the consumer should handle the absence gracefully rather than failing the entire transaction.
Logging and auditability cannot be overlooked. Each request should be logged with its unique trace identifier, along with the outcome, to provide a full audit trail. This is essential for compliance, governance, and incident investigation if something goes wrong.
Finally, long‑term maintainability requires systems to be designed for forward compatibility. As GP Connect evolves, new parameters and clinical domains may be introduced. Consumer systems should be able to ignore unsupported parameters without error, ensuring they remain functional as the specification develops.
When implemented well, the Parameters POST operation brings significant benefits to clinicians, patients, and the health system as a whole. Clinicians gain immediate access to reliable, up‑to‑date information that supports safe decision‑making. Patients benefit from joined‑up care, with reduced risk of errors such as contraindicated prescribing or missed diagnoses.
From a system perspective, the unified request model reduces the number of transactions and ensures that all requested data is gathered consistently and securely. The ability to tailor requests means that systems can deliver focused views of the patient record, enhancing usability and reducing cognitive load on busy clinicians.
Perhaps most importantly, the operation supports the wider vision of NHS digital integration. By enabling safe, standardised access to structured GP records, it breaks down silos and ensures that information flows to where it is needed most, supporting continuity of care and improving outcomes for patients across the health and care system.
Is your team looking for help with GP Connect integration? Click the button below.
Get in touch