/
Tales From George's Mind

Tales From George's Mind

George sent me some interesting notes about RDA feeds so I am dumping them here until I find a suitable home.

 

Pre-Mirth 

The files should be GPG encrypted with a filename of ABC123_00000_1234567890.xml.gpg.

The files should be encoded in UTF-8 (ASCII will also pass for this). We have a conversion process in place to handle UTF-16 files.

 

Python Conversion (via Mirth)

The file will be validated against the version of the UKRDC schema that is listed in the schemaVersion header attribute. It will be rejected if this fails.

If needed the file will be converted to version 3.5.3 of the schema via a number of steps. This may involve some items being stored separately from the XML files and in other cases fields like comments will be truncated. This is a requirement of some legacy components. If this process fails, the file would be rejected – however this is likely to be something we would fix here.

 

Python Validation (via Mirth)

If any of the following fail the file would be rejected. Only the triggering error is made available.

  • A SendingFacility must be present in 2 lookup tables in the UKRDC database.

  • Every patient must have exactly one MRN type identifier

  • If a UKRR_UID type identifier is supplied, it must have a prefix which corresponds to the SendingFacility

  • If an NHS/CHI/HSC identifier is supplied, it must pass the validation checks. This includes the checksum, the number range, and in the case of CHI numbers the additional demographic-based conditions.

  • Every patient must have a DOB

  • For the following fields, the dates must not be before the patient’s DOB unless they are “01/01/1900” or certain other placeholder dates that sites/suppliers are known to use. NOTE: It is likely further fields will be added and the checks will be expanded as for dates years in the future.:

    •         "./Observations/Observation/ObservationTime",

    •         "./Medications/Medication/FromTime",

    •         "./Medications/Medication/ToTime",

    •         "./DialysisPrescriptions/DialysisPrescription/FromTime",

    •         "./LabOrders/LabOrder/SpecimenCollectedTime",

    •         "./LabOrders/LabOrder/ResultItems/ResultItem/ObservationTime",

  • Any PostCode field (Patient Address, GP Address etc.) must pass the Royal Mail regex.

  • Where the item is in the form CodingStandard/Code/Description if CodingStandard or Code has been supplied both must be supplied.

  • Further to the above by default only supplying Description will also trigger an error. In most of these cases the preferred solution is to use a CodingStandard of LOCAL and whatever the local Code is, unless the field is free-text.

  • Any items with a CodingStandard of “SNOMED” must have a numeric Code.

  • With limited exceptions (such as “LOCAL”, and for now “SNOMED”) any item which supplies a CodingStandard will trigger a lookup to a Code table.

  • Where the fields are GP / GPPractice the data is checked against the NHS Reference list.

  • PlacerIds and FillerIds should only be used once per file. As discussed previously this is because we use the PlacerID (and if not supplied the FIllerID) as the PK in the LabOrder table. We appreciate that this may not match how data is structured in the renal systems.

  • For PRDs and CODs you can have 1 PRIMARY, 1 SECONDARY, and many OTHER types. You can’t have a SECONDARY without a PRIMARY etc.

  • For Medications you either need to supply an ID or a Name for the Medication.

  • [I can’t find this in the current code but…] There will be a check that if supplied each ExternalID can only be used once per patient. It is intended to be a reference to that item of data whereas one interface was using their Patient ID for each LabOrder in their file etc.

  

JTRACE

 Just to be comprehensive the files will also fail at our EMPI stage if –

  • They are missing basic demographics (which should have been caught earlier)

  • There is some ambiguity about whether the incoming file matches an existing record. We have a UKRDC Data Manager to address these issues.

 

Repository

 Again, to be comprehensive occasionally there will be a mismatch between what the schema will accept and what the underlying database will accept.