# **GD-1541**

## **Quicksilva ():**

*Documenation:*
- Creates a full date from the System.DateTime object
- Creates a date based on full or partial date supplied as a string. Please note, dateValue must be in the format of YYYY, YYYYMM or YYYYMMDD

## **MIG Vision / Emis (UTC):**

*1st Response from the support service:*
Patient trace birthdate: Vision - 1931-08-23
Patient trace birthdate: Emis - 1951-01-28

*2nd Response from the support service:*
UTC

*From EMIS Portal SDK specification:*
- things like requestTime and responseTime (used for logging) are in UTC:

<xs:attribute name="responseTime" type="xs:dateTime" use="required"> 

<xs:annotation> 

<xs:documentation>The UTC time at which this response was generated</xs:documentation> 

</xs:annotation> 

</xs:attribute> 

*From Final Data Set and Data Items JUYI phase one V3.9:*
- for date fields like 'Date', 'RelatedPerson.birthDate', 'RelatedPerson.period.start':

event.effectiveTime.value
Should already be in 'YYYY-MM-DDTHH24:MI:SS' format

- for Medicines 'CompletionDate':
`event.medication.expiryDate`

**TPP Community / GP ():**
-
*Integration:*
- logging - UTC
- CSV -> db - naive datetime

*Documenation:*
*From Final Data Set and Data Items JUYI phase one V3.9:*
- for Date field in Clinical observations & finding:

SRCode.DateEvent

- for Medicines 'CompletionDate':

SRPrimaryCareMedication.DateMedicationEnd

**Rio (UTC):**
-
*Documenation:*
- DateTime ( DD-Short Month-YYYY , for example 17-Jan-2017)
Dates and times must be passed through according to one of the following formats:

| Dates only | YYYY-MM-DD |
| -------- | -------- |
| Date and time | YYYY-MM-DD HH:MM+ZZZZ |
| | YYYY-MM-DD HH:MM:SS+ZZZZ |
| | YYYY-MM-DD HH:MM:SS.fff+ZZZZ |
| Time only | HH:MM+ZZZZ |
| | HH:MM:SS+ZZZZ |
| | HH:MM:SS.fff+ZZZZ |

Times must be sent to the API in 24-hour format and must include a timezone offset. Similarly, any times returned by the API will also include a timezone offset and be specified in 24-hour format. This format will allow for an unambiguous time to be exchanged regardless of whether daylight savings is in effect or not.

For example, 10:30pm GMT on 5 Jan 2013 would normally be sent as “2013-01-05 22:30:00+0000” but if sent as “2013-01-05 23:30:00+0100” would be correctly interpreted. Similarly 10:30pm BST on 23 July 2013 may be sent as either “2013-07-23 22:30:00+0100” or “2013-07-23 21:30:00+0000”.

**Adastra ():**
-
*Integration:*
https://github.com/KainosSoftwareLtd/gccg.velocity.etl.sourcedataextraction/blob/develop/Adastra/source/modules/processor/adastra_s3_service.py#L36
- naive datetime

*Documenation:*
No information

**Liquidlogic ():**
-
*Integration:*

https://github.com/KainosSoftwareLtd/gccg.velocity.etl.sourcedataextraction/blob/develop/LiquidLogic/source/modules/utils/date_parser.py
- naive datetime

*Documenation:*
- The format of the date data type is follows: CCYY-MM-DD (e.g. 2011-03-17)
- The format of the dateTime data type is follows: CCYY-MM-DDThh:mm:ss (e.g. 2011-03-17T10:20:23)

**Trakcare (UTC):**
-
*Integration:*

https://github.com/KainosSoftwareLtd/evolve.velocity.integration.iguana/blob/VIN-329-HL7-to-FHIR-New/shared/HL7v2%20to%20FHIR/mapUtils.lua
> os.time{year=t.year, month=t.month, day=t.day, hour=t.hour, min=t.minutes, sec=t.seconds}
- local time

*Documenation:*
- HL7 YYYYMMDDhhmmss format - UTC