DocumentReference date field behaviour

National Record Locator (NRL)
1

I’m finding the date we supply is being replaced with the current date/time

Is this something to do with the pointer we are using

"type": {
                    "coding": [
                        {
                            "system": "http://snomed.info/sct",
                            "code": "887701000000100",
                            "display": "Emergency health care plan"
                        }
                    ]
                },

Our document will be static and so we want the date we supply to be used. I’m presuming the changing data value is something to do with retrieving dynamic documents.

p.s. we will be asking for our own pointer type, we are using the one above for testing purposes on Int.

2

Hi Kevin, you’re correct that the .date field is populated by NRL, that is by design.

Per FHIR, the .date in a DocumentReference - FHIR v4.0.1 represents “When the document reference was created” so we use the datetime that the pointer made it into our database.

The field that represents the creation of the document itself is the optional .creation in the content.attachment entry for the document: Datatypes-definitions - FHIR v4.0.1

3

thanks

That looks a bit odd compared to the pattern used elsewhere in FHIR but it seems correct.

I’m not sure if it should be when NRL created the DocumentReference or when the original system did? I’m working on a middleware component.

I’ll bring it up when (/if) we start onboarding.

4

Agreed that it’s a bit unusual. Part of the reason we put in that default behaviour was that there was so much confusion.

We do have a mechanism to ignore the .date override that we use for other applications that are sending us DocRefs from existing systems rather than creating new ones in the NRL3. It seems like yours would be suitable for that configuration. Let us know when you get to that point :slight_smile:

5

Thanks.

I’ve fitted in (clinical) date in under context.period for now

  "context": {
    "period": {
      "start": "2025-10-15T15:59:16+00:00",
      "end": "2025-10-15T15:59:16+00:00"
    },

That is correct if my source systems are IHE XDS/MHD based and I can map HL7 v2 sources to that also.

I can treat the other two dates as technical dates.

1 Like