Inbound Data Transform Specifications
Introduction
This article forms the basis of the technical implementation of any new inbound transform of data into the Discovery Data Service (DDS), specifically for non-transactional flat file formats.
The aim is to ask potential publishers to consider and answer the following questions:
- How will the source data be sent to DDS? Will it be an SFTP push or pull? Will the files be encrypted? See Secure publication to the DDS for currently supported options.
- How often will the source data be sent to DDS? Will it be sent in a daily extract? See Latency of extract data feeds to see how often and when data is currently received, and how that relates to the data available in the DDS.
- How should the source data be mapped to the FHIR-based DDS data format? What file contains patient demographics? What column contains first name? What column contains middle names? See Publishers and mapping to the common model for more information.
- How should any value sets should be mapped to equivalent DDS value sets? What values are used for different genders and what FHIR gender does each map to?
- What clinical coding systems are used? Are clinical observations recorded using SNOMED CT, CTV3, Read2, ICD-10, OPCS-4 or some other nationally or locally defined system?
- How are source data records uniquely identified within the files? What is the primary identifier/key in each file and how do files reference each other?
- How are inserts, updates and deletes represented in the source data? Is there a 'deleted' column?
- Is there any special knowledge required to accurately process the data?
- Will the publishing of data be done in a phased approach? Will the demographics feed be turned on first, with more complex clinical structures at a later date?
- What files require bulk dumps for the first extract and which will start from a point in time? Will a full dump of organisational data be possible? Will a full dump of master patient list be possible?
- Is there any overlap with an existing transform supported by DDS? Does the feed include any national standard file that DDS already supports?
Questions that need to be answered are highlighted throughout this article:
| This is a question that needs to be answered. |
The understanding of the answers provided can then be used by the DDS technical team to implement the technical transformation for the source data.
Completion and sign off of the specifications is a collaborative process, involving the data publisher (or their representatives) and the DDS technical team; the data publisher has a greater understanding of their own data, and the DDS technical team have experience of multiple and differing transformations.
DDS inbound overview
This diagram provides an overview of the way the DDS processes a sample of existing inbound data feeds. Each data publisher has their own transport mechanism for getting data into the DDS estate (SFTP push, SFTP pull, bespoke software) which is then sent through a common pipeline that performs a number of checks (most importantly validating that DDS has a data processing agreement to accept the data). Once the checks are passed, the data is handed over to the DDS transformation application, that then invokes the relevant transform code for the published data format. The result of the transformation code is standardised FHIR that is saved to the DDS database; this may be further transformed for any subscribers to that publisher’s data.
Unless there are exceptional circumstances that preclude it, all DDS software is written in Java, running on Ubuntu.
| the image represents the logical flow of data into the DDS, rather than the distinct software components themselves. |
Publishing process
The end to end process for publishing new data into the DDS generally follows the below steps. This isn’t necessarily a fixed-order list, as many of the steps can be performed out of order or in parallel to other steps, but it covers all the actions that need to happen.
- Agree extract transport mechanism and frequency.
- Define project phases based on data types and dependencies.
- Set up transport mechanism and test (this can be done at any point before live data is sent).
- For the first phase:
- Provide file extract format specification.
- Provide sample data.
- Validate and assure the published data.
- Define how inserts, updates and deletes are represented.
- Define transformation mapping.
- List any known special cases.
- Sign off transform specification document.
- Implement transform code to specification.
- Validate and assure new code using sample data (if possible).
- Start live feed of data, bulk followed by deltas (data will be securely stored but won’t flow into production DDS yet).
- Validate and assure code using subset of live data (in secure pre-production environment).
- Deploy new code to production DDS and start processing data.
- At this point, this phase is now considered live.
- If required, repeat step 4 for the subsequent phases.
Assurance and sign-off
Assurance and sign-off is required at three distinct stages of the publishing process:
Extract assurance
The data publisher must assure that their data extract accurately represents the data in the source clinical software.
How this assurance is done will vary from publisher to publisher, although the DDS team may be able to provide some guidance on how to conduct this.
Transform specification sign-off
Both the publisher and DDS team must agree that the completed transform specification document is accurate and sufficient to implement the transformation code.
This will be done when both parties agree that the document has been sufficiently completed.
Transform assurance
Once the transformation implementation is complete, it must be assured that it can accurately transform the source data into the DDS format.
This will generally be done in two passes, once on sample data and a second time on live data. This will involve comparing the data in the pre-production DDS against the source software.
Transport mechanism & frequency
The goal of the transport mechanism is to securely send the extract files into the DDS estate (hosted in AWS with HSCN connectivity). The frequency defines how often files are sent.
For context, these are examples of existing publisher scenarios:
- A daily extract of 100+ files but staggered throughout the day. As each file is produced it is uploaded to a DDS SFTP server over HSCN (secured with an SSH key). As the SFTP server receives new files, these are moved into the secure file store. At midnight, the files received that day are sent for transformation.
- A daily extract of 20 files. The files are PGP compressed and encrypted and made available on an SFTP server the publisher hosts on HSCN (secured with an SSH key). Each hour, a DDS SFTP client polls the SFTP server for new files. When new files are detected, they are downloaded and decrypted, then stored in the DDS secure file store. Once DDS has received the full set of 20 daily files, the new files are sent for transformation.
- A single daily zip file using their own client software to a Windows PC workstation hosted within a CCG building. A small DDS-written application runs on the workstation and detects each new extract file, which is then uploaded via HTTPS over HSCN to a DDS API. The DDS API unzips the file and stores the decompressed files in the secure file store, which are then sent for transformation.
| How many files will be produced in your extract and how often, and how you see them being transported to the DDS? |
| It is recommended that any transport be done using SFTP, secure using an SSH key and over HSCN. For further security, it is also recommended that extract files be encrypted themselves before transport. |
Scheduling and dependencies
Depending on the complexity of the published data it may be necessary to split the implementation into several phases, each phase introducing new data to the DDS. For example, if a secondary care publisher extract contains data on organisational metadata, patient demographics, procedures, diagnoses, and clinical observations, it may be more efficient to break the implementation into several discrete phases for implementation; For example, doing the full procedures implementation before doing conditions, and then finally moving on to observations.
However, because some data naturally depends on other data, the dependencies must be understood to know what data items must be done before others. For example:
- Organisational metadata is always required first, since everything depends on organisations, locations and clinicians.
- Patient demographics are always required next, since all other clinical data depends on matching to patient records.
- A&E attendances, inpatient stays and outpatient appointments are generally required next.
- Finally, procedures, conditions and observations can be interpreted.
| Is scheduling necessary? What are the dependencies within the data? |
| The scope of the first phase should now be agreed. |
Extract file specification
| Can you supply technical extract documentation such as file specifications? |
Sample data
| Can you provide sample data? |
| Sample data should include fictitious patients only but be as realistic as possible. It should also be in the exact same format as the planned extract. |
Inserts, updates, and deletes
The ideal scenario is that each file within the extract is sent initially as a bulk extract followed by regular deltas (differences only), with clear indication of which records are new, which are updates, and which are deleted.
| Can you explain how the extract represents updates and deletes to data and whether it will be possible to follow the bulk, then deltas pattern? |
Transformation mapping
All inbound DDS transformations, for different source formats, output FHIR using a DDS-specific profile. Approximately 20 different FHIR resources are used in DDS to date. Each FHIR resource has many fields of different types, some mandatory, some not.
The sections in Resource mapping list all the fields for each resource type that the DDS uses.
| Each field requires you to describe where that field can be found in the source data and what, if any, mapping or formatting is required. |
Links to the original FHIR definitions on the HL7 website are also provided, to give more detailed explanations on what each resource is for.
| Field names may not be the same as on the HL7 website and/or may not even be on the HL7 website at all; the DDS uses a number of FHIR extensions to add additional fields to each resource. |
Guidance
The cell for each resource field asks for the source location and mapping. Not every field will require any mapping, so leave this blank if the value should be taken as is.
| Field name: | Date of birth |
| Type: | Date |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Patient’s date of birth |
| Source location: | “DoB” column, Patient_demographics.csv |
| Mapping: | Date format YYYYMMDD |
Example resource field
The following sub-sections provide additional guidance on more complex scenarios that should be considered when completing these cells.
Other Resource Fields and Types
The 20+ resource types in Resource mapping are the ones used by the DDS to date out of a possible 150+. If you have data that cannot be mapped to any of them, then raise this issue with the DDS team and additional resource types will be added if necessary.
Similarly, the fields used in each resource type are only the ones that have been necessary to use to date. If the data has key information that has no obvious place in a resource, then raise this issue with the DDS team, so new fields can be made available if necessary.
Dates and Times
For date and datetime fields, please specify the format the source data is provided in, For example, YYYYMMDD or DD-MM-YYYY HHMM.
Multiple Files
If multiple extract files supply data for a single resource, then describe how the two files relate to each other, such as what the primary and foreign keys are.
For example, if patient addresses are supplied in a separate file to the other patient demographics, then the primary key for both files needs to be understood, as does how the address file refers to the main file.
De-duplication
If the same data is present in multiple files, then explain how the data can be processed to avoid de-duplication.
For example, one DDS publisher feed supplies procedure (such as an operation) data in four files derived from a data warehouse and two files in a national CDS standard. Each logical procedure may be present in one or more of these files, and there is no common unique ID to identify the same procedure throughout. To avoid duplicate procedures in DDS, analysis of the source data to create a de-duplication strategy was required.
Reference Data
If understanding of the data requires reference data that is not part of the extract feed itself, then consider how this reference data can be supplied to DDS. For small and static reference data set, an ad hoc arrangement can be made where the reference data is manually loaded into the DDS for later look up. For large or frequently changing reference data sets, the reference data itself should be made part of the extract.
For example, one DDS publisher feed has all clinical observations (such as height and weight) coded using SNOMED CT, but the extract file containing the observations is coded using an internal integer which refers to a semi-static reference table which in turn provides the SNOMED CT concept ID. To ensure that the DDS can always look up a SNOMED CT concept ID for every observation, the coding table itself is part of the extract.
Supported File Formats
The DDS already supports a number of transformations from national file CDS formats, such as the SUS Inpatient and Outpatient files. If any of these files are to be used, the existing transform can most likely be reused and the transformation mapping won’t need to be re-defined for them.
Special Cases
Requirement
In all data extracts that the DDS receives there are special cases that aren’t evident from the extract specification or mapping process; these need to be fully understood to safely and accurately transform the data.
Examples of previously encountered special cases:
- A publisher sent BST times and datetimes in UTC in some, but not all, of their extract files. This meant that in some files, an event that took place at 16:00 was shown as taking place at 15:00, and more noticeably an event that took place at midnight showed as having happened at 23:00 on the previous day. This inconsistency in times is a special case that was mitigated for, so any affected file has timed adjusted by an hour, so that events in DDS show with the correct time (and date).
- A publisher sent extracts instructing the DDS to delete all patient data (a delete for every patient) if an exception was thrown during the extract generation. The publisher’s software error handling detected the exception and rather than simply not produce an extract for that date, sent a valid extract but with a delete statement for every record. If DDS processed this mass delete, the only way to restore the data was to take a fresh bulk extract of all the data and process it. This special case was mitigated for by detecting the mass delete and raising an alert with the DDS technical team rather than automatically processing it.
| Can you provide details of any known special cases that do or can occur with the extract? |
| It is expected that special cases won’t necessarily be known until the transform has been implemented and the data transform is going through testing and assurance, but that knowledge must be recorded as and when it is found. |
Resource mapping
Resource: Organisation
Represents an organisation, such as a GP practice, hospital department, CCG, or trust.
Defined at http://hl7.org/fhir/organization.html
ID
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique identifier within the extract (primary key) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Name
| Field name: | Name |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Organisation’s name |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Identifier
| Field name: | Identifier |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | National identifier for the organisation (ODS code) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Main location
| Field name: | Main location |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Unique ID of a Location resource that represents the primary location this organisation operates from (main surgery site for a GP practice) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Parent organisation
| Field name: | Parent organisation |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Unique ID of an organisation resource that this organisation belongs to (CCG organisation for a GP practice) to allow organisational hierarchies be represented |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Type
| Field name: | Type |
|---|---|
| Type: | Value set |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Organisation type.
If not possible to map to the value set, a free-text type can be supported. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Open date
| Field name: | Open date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Date the organisation opened |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Close date
| Field name: | Close date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Date the organisation closed |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Address
| Field name: | Address |
|---|---|
| Type: | Address sub-structure |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | The organisation’s address |
| Field name: | Line |
|---|---|
| Type: | Text |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | Number, house name, road and locality |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | City |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | City or town |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | County |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | County |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Postcode |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Postcode |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The use of the address (work).
For organisations, it may be possible to just infer that all addresses are work addresses. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Telecom
| Field name: | Telecom |
|---|---|
| Type: | Telecom sub-structure |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | The organisation’s list of contact methods (phones, faxes and emails) |
| Field name: | Value |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Contact value (phone number, email address) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | What this contact method is used for (work).
For organisations, we may simply infer that all contacts are for work purposes. See http://hl7.org/fhir/valueset-contact-point-use.html |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | System |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The type of contact method this is (phone, fax, email). |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Resource: Location
Represents a physical location.
Defined at: http://hl7.org/fhir/location.html
ID
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique identifier within the extract (primary key) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Name
| Field name: | Name |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Location’s name |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Identifier
| Field name: | Identifier |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | National or local identifier for the location |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Main contact name
| Field name: | Main contact name |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | No |
| Description: | Name of main person responsible for this location (manager) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Part of
| Field name: | Part of |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Unique ID of a parent Location if this location is part of a hierarchy |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Managing organisation
| Field name: | Managing organisation |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Unique ID of an Organisation that this Location belongs to |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Physical type
| Field name: | Physical type |
|---|---|
| Type: | Value set |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | What type of location this is (room, wing, building).
See http://hl7.org/fhir/valueset-location-physical-type.html |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Open date
| Field name: | Open date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Date the location opened |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Close date
| Field name: | Close date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Date the location closed |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Address
| Field name: | Address |
|---|---|
| Type: | Address sub-structure |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | The location’s address |
| Field name: | Line |
|---|---|
| Type: | Text |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | Number, house name, road and locality |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | City |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | City or town |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | County |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | County |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Postcode |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Postcode |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The use of the address (work).
For locations, it may be possible to just infer that all addresses are work addresses. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Telecom
| Field name: | Telecom |
|---|---|
| Type: | Telecom sub-structure |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | The organisation’s list of contact methods (phones, faxes and emails) |
| Field name: | Value |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Contact value (phone number, email address) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | What this contact method is used for (such as work).
For organisations, we may simply infer that all contacts are for work purposes. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | System |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The type of contact method this is (phone, fax, email). |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Resource: Practitioner
Represents an individual working at an organisation, such as a clinician or administrator.
Defined at http://hl7.org/fhir/practitioner.html
ID
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique identifier within the extract (primary key) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Managing organisation
| Field name: | Managing organisation |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique ID of the Organisation that this Practitioner belongs to |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Role start date
| Field name: | Role start date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Start date of this practitioner in this role |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Role end date
| Field name: | Role end date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | End date of this practitioner in this role |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Active
| Field name: | Active |
|---|---|
| Type: | Boolean |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Boolean flag to define if this practitioner is active or not. Can be used if explicit start and end dates are not available, but if they are available then this should not be used. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Job role code
| Field name: | Job role code |
|---|---|
| Type: | Value set |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Code to define the job role.
See https://fhir.hl7.org.uk/STU3/CodeSystem/CareConnect-SDSJobRoleName-1# |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Speciality
| Field name: | Specialty |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Secondary care specialty this Practitioner works in |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Name
| Field name: | Name |
|---|---|
| Type: | Name sub-structure |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Practitioners current name |
| Field name: | Prefix |
|---|---|
| Type: | Text |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | Title or anything that would proceed the name |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Given |
|---|---|
| Type: | Text |
| Cardinality: | 1..n |
| Required: | Yes |
| Description: | First and middle names |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Family |
|---|---|
| Type: | Text |
| Cardinality: | 1..n |
| Required: | Yes |
| Description: | Surname(s) / last name(s).
Note: Hyphenated surnames are not split into separate elements, but other double surnames are. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Suffix |
|---|---|
| Type: | Text |
| Cardinality: | 0..n |
| Required: | No |
| Description: | Any title or honorific that would appear after the name (such as OBE) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Identifier
| Field name: | Identifier |
|---|---|
| Type: | Identifier sub-structure |
| Cardinality: | 0..n |
| Required: | No |
| Description: | Any identifiers for the practitioner (such as GMC number) |
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Yes, if multiple identifiers of the same type are provided.
No, if only a single identifier of each type is provided. |
| Description: | Unique ID for this identifier record |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Value |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The actual value of the identifier |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | System |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | What kind of identifier this is (GMC number).
Note: This value set isn’t fixed, new options can be added. |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Start date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Start date of the identifier |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | End date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | End date of the identifier |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Address
| Field name: | Address |
|---|---|
| Type: | Address sub-structure |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | The practitioner's address |
| Field name: | Line |
|---|---|
| Type: | Text |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | Number, house name, road and locality |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | City |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | City or town |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | County |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | County |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Postcode |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | Postcode |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The use of the address (work). |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Telecom
| Field name: | Telecom |
|---|---|
| Type: | Telecom sub-structure |
| Cardinality: | 0..n |
| Required: | Recommended |
| Description: | The practitioners’s list of contact methods (phones, faxes and emails) |
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 0..1 |
| Required: | Yes, if multiple telecoms are supplied per practitioner.
No if only a single telecoms is supplied. |
| Description: | Unique ID for this telecom record |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Value |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Telecom value (phone number, email address) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Start date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | No |
| Description: | Start date of the telecom |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | End date |
|---|---|
| Type: | Date |
| Cardinality: | 0..1 |
| Required: | Recommended |
| Description: | End date of the telecom |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Use |
|---|---|
| Type: | Value set |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | What this telecom method is used for (work). |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | System |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | The type of telecom method this is (phone, fax, email). |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
Resource: Patient
Represents the top-level of the patient record, containing name and other demographics.
See http://hl7.org/fhir/patient.html
ID
| Field name: | ID |
|---|---|
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique key for the patient in the source data (primary key) |
| Source location: | What file and field contains this? |
| Mapping: | Is any mapping or formatting required? |
| Field name: | Managing organisation |
| Type: | Text |
| Cardinality: | 1..1 |
| Required: | Yes |
| Description: | Unique identifier of the Organisation resource that represents the publisher of the data e.g. if data is published from a Out of Hours Call Centre, this field will refer to the Organisation representing the call centre itself. |
| Source location: | TODO: What file and field contains this? |
| Mapping: | TODO: Is any mapping or formatting required? |