Comments on the FDA eSource Guidance draft update – Nov 2012

The FDA have released the much anticipated update to the eSource Guidance first sent out for draft review back in December 2010. Once again this is a draft release for comment rather than a final release.

First Impressions

First impressions are that the guidance is somewhat shorter and more to the point than the 2010 draft. Although I welcomed the fact that the FDA were tackling many of the issues, I don’t believe that all of the items covered in the first draft were directly associated with eSource. For example, the Tier architecture references.  These have been removed from this 2nd draft.

The guidance positively encourages the entry of source data directly into an eCRF. This is welcome. In the past it has been felt by some, although not myself,  that regulations implied that data could not be captured directly as eSource into an EDC system. Based on this guidance,  if you want to use online EDC – you can.

The definition of Data Originator opens up the scope of who is able to provide source data.  This includes Study Subjects.  With controls in place it is now entirely valid for a study subject to enter their own data directly into an eCRF.

For those of you looking for this 2nd draft guidance it can be downloaded here

Detailed Commentary

I have commented on the guidance by line number for easy reference;

  • line 175 – transmission of data directly from an EHR system. This makes it clear that data can be sent directly from an EHR and that auditors will consider this as equivalent to data entered from paper. Without actually stating this, it means feeding systems out with the control of the sponsor do not need to be 21 CFR Part 11 compliant. It does mean that Monitors will need to be given access to EHR systems.   I think this might be an error in the guidance.
The guidance attempts to differentiate between automated EHR data transmission versus other device data transmission.  With the former, source data is in the EHR, with the latter, source data is considered only in the eCRF. I can understand why, but, I think limiting the definition to specifically EHR systems is not correct.  A better method would be to state that where the mapping / interface is not validated, then the source should remain in the providing system, and verification should be carried out between systems.
  • line 185 – Data Element identifiers – the draft persists with the reference to data element identifiers. This is confusing and I believe an incorrect definition of how data from external devices would be identified when loaded into an eCRF. When data is keyed, it must be audit trailed against the user that keyed the data. For data electronically transferred – say from an ECG device – then of course a ‘user’ might not be directly involved. Today, typically a dummy user is utilised by EDC systems. All data loaded from any device is loaded in under this ‘dummy’ user system account. In theory, this could create a duplicate record challenge. To differentiate data between devices, this dummy user must be different from device to device, or, an additional field defined that logs the device id. From a database design perspective it may prove easier to leverage the existing support that associates data to a user account and simply have created multiple dummy system user accounts – 1 per device. There is a danger that the present draft guidance excludes the use of this most likely implementation methods.What I believe the guidance is attempting to describe is an index or context key for a data item.
  • line 209 another complication of the use of data element identifier. Data entry modifications should not obscure previous entries. This might be misunderstood. Audit trails will show previously values but they will be obscured behind the eCRF itself. The audit trail must be viewed to see the previous entries.
  • line 213 – good to see a recognition of point of entry edit checking and flagging of data to improve quality. This will undoubtably be used against products that continue to rely on back-end  batch checking (a good thing!).
  • line 240 – we have another reference to Data element identifier in the context of describing the logging of the investigator signature which in this case would seem to be an audit trailed flag. I think this is an error. An audit trail record would also have an index or context key but this is not as described in the definition of a data item identifier.
  • line 267 – data review and sign-off by other users. Earlier in the guidance it states that the investigator must review and electronically sign. The guidance should make clear that the investigator can indeed delegate review and signing responsibility at line 236
  • Line 277 – Under the section – Retention of records by the Investigator – Access to a signed electronic copy of the eCRF should be available for inspection..  It should be made clear that the signing part stated may be the electronic signature that is manifested in the copy, rather than a need for the investigator to sign to confirm the copy.  Systems that produce the copy should be validated to assure a copy is indeed a true copy.   This is not an activity that can be easily performed by an Investigator.
  • Line 360-369 – Further to the above – Electronic Source Data / Source Data Definition – one of my biggest concerns with the previous draft, that appears to be repeated here. It persists in stating that copies of Electronic Source Data must be certified copies.  This is incorrect.  The investigator should not be required to validate that an electronic copy (backup for example) is a certified copy.  The definition of Source does not hold true here for eSource and should be separated.
There is a potential point of confusion in the definition of metadata.  This is not uncommon in the clinical trials field, as the term ‘metadata’ has come to mean many things.
I think the draft needs to split the mixed use of the term metadata.  If you read the well written article on metadata from Wikipedia, it eloquently describes the difference between Structural Metadata and Descriptive Metadata:-
The term metadata is ambiguous, as it is used for two fundamentally different concepts (types). Although the expression “data about data” is often used, it does not apply to both in the same way. Structural metadata, the design and specification of data structures, cannot be about data, because at design time the application contains no data. In this case the correct description would be “data about the containers of data”. Descriptive metadata, on the other hand, is about individual instances of application data, the data content.
The term metadata in EDC systems often refers to the Structural Metadata.  For example, the form and field definitions.  These are static, and do not change ‘per data’.  The guidance is talking about ‘Descriptive Metadata’ such as a datapoint status, date of change or signature.
In Line 244-247, it states that the metadata should reflect the originator and the person signing.   Adding the definition of metadata as being Descriptive Metadata in the definition section would help. This also applies to the definition of tagging data elements in 240-242 where the term metadata is describes at equivalent to the data item identifier.   A key is certainly not metadata, so this part is in error.

A correction that I believe the document needs is the definition of Data Item Attributes in addition to Data Item identifiers. Attributes are not identifiers or keys to the data, they are attributes or flags associated with a data item.  You could argue that Data Item Attributes = Descriptive Metadata.  But, Data Item Identifiers not= Descriptive Metadata.   They are keys to the data.


One item I believe that is missing from the guidance is clarity around copying of eSource.   If a system is validated, then I believe that it is appropriate to assert that a copy of eSource is the same as the original.  This is critically important as the present guidance leaves it open to interpretation that only the first instance of the eSource can be considered source without an investigator certifying subsequent copies.

Source Data Verification is not mentioned.  This is unfortunate as this continues to be a point of considered risk within Pharma.  What I would have like to have seen has more guidance on verification responsibilities making it clear even when data is not eSource that it does not necessarily require SDV.

Despite my comments above, overall, I think the guidance is a good positive step that clarifies interpretations that will smooth and accelerate the capture of data in clinical trials.

Leave a Comment