Warning!

This application has been migrated to Atlassian Cloud.

Any changes made here may be lost. Please use the above link for all work going forward.

Page tree
Skip to end of metadata
Go to start of metadata

Types

Simple Types

SendingFacility
xs:string (restricted)
maxLength: 7

Complex Types

SendingFacility
extends SendingFacility
@ channelName
@ channelId
@ time
@ schemaVersion
SendingExtract
The extract process within the facility which produced this file.
SendingExtract
Patient Patient
LabOrders
Lab Orders. These are measurements taken about a patient that have been processed by a Laboratory. Our EHR structure requires that all test results are associated with a lab order. If the details of the lab order are not received by the renal system then a generic lab order should be created to contain all results with a common sample time.
LabOrders
SocialHistories
Other Health Related Behaviours.
SocialHistory* SocialHistory
FamilyHistories
This is used to record information about conditions diagnosed in the Patient's relatives. This element should not be submitted without prior discussion with the UKRR
FamilyHistory* FamilyHistory
Observations
Observations. These are measurements taken about a patient that do not involve a Laboratory.
Observations
Allergies
Allergies
Allergy* Allergy
Diagnoses
Diagnosis*
Co-Morbidities
Diagnosis
CauseOfDeath
Cause of Death
CauseOfDeath
RenalDiagnosis
Primary Renal Diagnosis. These should be used to record the Primary Renal Disease (defined in the ERA-EDTA PRD spreadsheet, notes for users, sections: 'Description of PRD' and 'Selection of the most appropriate PRD' http://www.era-edta-reg.org/prd.jsp ) for analysis by the UKRR, SRR and ERA. In order for the data to be comparable across countries it needs to be coded in using the EDTA code lists. Consequently we expect that some conditions may appear both as PRD objects and as generic diagnoses coded in SNOMED. Patients who started RRT after 01/01/2014 should be coded using the 2012 "EDTA2" code list. Patients who started before then can continue to be submitted using the older EDTA list. Systems should not automatically convert the older codes to the newer ones as this results in a loss of accuracy.
RenalDiagnosis
Medications
Medications. All recorded medications should be submitted whether or not prescribed for the purposes of renal care.
Medication* Medication
Procedures
Procedures
Procedure* Procedure
DialysisSessions*
Dialysis Sessions
DialysisSessions
Transplant*
Transplant Procedures.These should be used to record any Transplants. A single Procedure should be recorded for each organ being transplanted, with multiple organ transplants being identified by multiple transplants occurring on the same day. The record also contains information about the source donor for each transplant.
TransplantProcedure
VascularAccess*
Vascular Access Constructions
VascularAccess
Documents
Documents
Document* Document
Encounters
Encounter*
This is used to record the duration of something other than a Treatment. This element should not be submitted without prior discussion with the UKRR.
Encounter
Treatment*
This is used to record the duration a Patient received a particular type of Care/Treatment at a particular Treatment Facility. It is similar in concept to the UKRR TXT records however at the end of the period it should be end-dated rather than an additional record being sent. It is possible for treatment records to overlap if a patient has multiple treatments (such as post-transplant dialysis). A treatment record should exist for any period of time where they would be considered a patient (so for example code 900 record for pre-RRT CKD and a code 94 record for post-RRT Conservative care). Details of Transplants themselves should be recorded as Procedures but Treatment records should be used to record periods of Transplant related Inpatient/Outpatient care.
Treatment
TransplantList*
This is only for NHSBT supplied Transplant Waiting List data.
TransplantList
ProgramMemberships
Program Memberships. These are used to record whether or not a patient wishes to participate in one of the UKRDC’s member projects. In the case of projects such as RADAR the Program Membership record should only be closed if the patient actively wishes to withdraw. It should not be end dated when they leave the unit or die. If a patient decides to leave a project and then re-joins a new Program Membership record should be created (with a different ExternalID) rather than re-opening the original one.
ProgramMembership* ProgramMembership
OptOuts
Opt-Outs
OptOut* OptOut
ClinicalRelationships
This is used to record the relationship between a Patient and a Clinician or Care Facility. This element should not be submitted without prior discussion with the UKRR.
ClinicalRelationship* ClinicalRelationship
Surveys
Surveys
Survey* Survey
PVData
This is used internally to hold data items sent in PV XML files and should not be sent by external parties.
PVData

Schema

<PatientRecord>
    <SendingFacility>REE01</SendingFacility>
	<SendingExtract>UKRDC</SendingExtract>
</PatientRecord>

SendingExtract

SendingExtractDescription
SURVEYSurvey data (YourHealth, OPTEpro)
PVMIGData taken from the PV2 Database
HSMIGData taken from the HealthShare Database
PVData sent from Units in PV XML Format
RADARData from the RADAR System
UKRDCData supplied directly in RDA Format
MIRTHData supplied in RDA Format which has been produced by our UKRDC Extract Tool