This is a question that many of us in the clinical document management space are currently asking ourselves following the announcement by CareLex of their intention to develop and launch an industry eTMF standard under the auspices of OASIS. There already exists a sub-team within the DIA TMF Reference Model working group who are looking at developing metadata to support the Reference Model so the obvious question is “Why is another group necessary?”.
Well first off, the intention of the DIA TMF Reference Model group is not to develop a standard and DIA are not in the business of developing standards or endorsing standards. Our remit within DIA is to develop a conceptual model that can be adopted and adapted by industry to support clinical document management needs. As part of this, the metadata sub-team are developing standard nomenclature for core and recommended document attributes. This is a valuable exercise and will continue but the difference between these deliverables and a formal technical standard need to be recognized. A technical standard – which is outside the remit of the DIA team – is to facilitate data and document exchange between any two systems that are compliant with the eTMF standard. This currently requires bespoke (i.e. expensive and time-consuming) programming and consultancy to get two eTMF systems talking to each other. Furthermore, the availability of an eTMF technical standard would facilitate the development of generic eTMF Viewers that could be used in a simple browser interface to interrogate and access ANY compliant eTMF system. The OASIS eTMF Standard Technical Committee will be supportive of and complementary to the DIA TMF Reference Model activities.
So why OASIS? Well, in the conversations I’ve had, various alternative standards groups have been mentioned. Each group has advantages and disadvantages and it becomes a rather subjective exercise to pick one to go with. Here’s a quick summary of some of the points I’ve picked up along the way. OASIS has already developed an authoritative standard for content management interoperability (CMIS) that is used by many of the big software vendors such as EMC, Microsoft, Adobe. OASIS is already supported by many of the major content management vendors. Whilst groups like HL7 and CDISC have experience in data exchange, OASIS has more experience in developing standards for content and document exchange. So far, HL7 has not expressed any interest in hosting or being involved in an eTMF initiative.
OASIS also has a reasonable history at developing standards within a rapid timeframe. The goal is to publish a draft standard within 6-9 months; OASIS Technical Committees have achieved this where other standards groups typically take longer.
Several have commented on the seemingly expensive cost of engagement with OASIS. To participate directly in an OASIS Technical Committee, a person must either be an individual member of OASIS ($310 per year) or their employer must have company membership. Company membership fees vary from $3,350 to $8,400, providing contributor access for all company employees. This compares to a minimum of $1,200 plus $3,500 joining fee for CDISC for the smallest company (<20 employees) up to $25,000 plus $30,000 joining fee for companies with >25,000 employees. Similarly, membership to HL7 costs $705 per year for an individual to up to $19,635 for larger companies. So from a cost perspective, OASIS appears a reasonable choice. Furthermore, non-OASIS members will still have opportunities to engage in this process via the DIA TMF Reference Model group; the two initiatives are not competing with each other!
So we come back to my original question….. is a standard necessary? From my experience working with many different clients, I see a key issue causing a stumbling block on almost every TMF project; this is the impact caused by the inherent flexibility of the TMF Reference Model. By virtue of the fact that it is a reference model and not a standard, each organization has its own interpretation of the model. This is initially seen as great for the organization as it often means not needing to change their current file plan for TMF content. Inevitably, it leads to plenty of man-hours mapping file plans to the Reference Model and vice versa. More importantly however, the subtle difference between Reference Model implementations results in an inability to easily exchange data and/or content between systems. Does this mean the TMF Reference Model has no value? Of course not! It still has value in determining the underlying content and structure of the TMF for regulatory and business purposes. It has done perhaps more than any other single thing to improve TMF compliance. Does a standard mean loss of flexibility? Absolutely not! An eTMF Standard can still mean Company A or Vendor A displaying TMF content using a different file plan than Company B or Vendor B. However, the primary attributes that identify and describe each document within the eTMF will be the same; the only difference will be how the content is surfaced in the user interface. As an analogy, there exists a technical standard for electronic calendaring. Both Google Calendar and Microsoft Outlook Calendar comply with the standard for data exchange but calendar items appear very different in both systems; field names are sometimes different, with each having different options. However, compliance with the standard enables you to send me a Google Meeting Request and me to receive that Meeting Request into my Microsoft Outlook Calendar. An eTMF Standard should achieve the same for eTMFs. Wingspan to Veeva. FirstDoc to PhlexEview. NextDocs to Transperfect. Or…. view your eTMF archive through a generic web-browser eTMF Viewer Add-in! See you on the OASIS Technical Committee or eTMF Standards LinkedIn Group?