A couple of week ago I wrote a post about the prototype metadata tool I developed to look at metadata and research concepts (for more information on Research Concepts see this post) at a practical level.
One item I highlighted in that post was the organisation of the menu structure:
One feature I would point out is the main menu on the left, the items within it and the separation between items. Work from the top, ignoring the home option, you see Terminology, Templates and Concepts, Forms and Domains and then Studies. This represents the expected workflow and user role separation expected to be seen within a sponsor organisation. Also the Study versus the remainder of the items reflects the separation between the Metadata Repository function and the tool(s) that use the MDR content.
I organised the menu items in the toolset aligned with what I see as the ‘functions’ needed by users and I see these functions being tightly aligned with the skills and roles that will be needed when users come to govern their metadata. Consider the diagram to the left. It reflects the organisation of metadata that you will probably have seen in quite a few CDISC presentations at interchanges and elsewhere.
You will see I have two halves; one for CDISC and one for the Sponsor but both based on the BRIDG model as their foundation. Working up from the BRIDG layer:
- Terminology – Both CDISC and sponsors will be developing and producing terminology. We all know what CDISC produces today and the current rate of expansion but there will always be gaps, even if those gaps are small. So we need the skills to manage terminology but also create new items and use those items within code lists. CDISC have these skills incorporation with the National Cancer Institute (NCI). Most sponsors have these skills.
- Research Concept (RC) Templates – You will see there is a gap on the sponsor side. I really want CDISC to give me the templates that I can use based on BRIDG. This way we can hide BRIDG complexity from the vast majority of users and keeps things simple for users (note I want well structured templates, hence BRIDG, but once I have the rigour from the structure I want to hide complexity). Bigger companies may choose to have these skills, those heavily involved in helping CDISC with content development may want to understand these aspects, but it would be nice for those who don’t to be able to hide the BRIDG level and just understand how to use a template rather than how to construct one.
- Research Concepts – I would expect that, whoever many CDISC give me, a sponsor will always need to create their own; the new lab test, the new science. There will always be something new. So content experts will be needed. Currently we see these skills being deployed within the Therapeutic Area development work being undertaken by CDISC. A lot of this work is really focused around RC development along with the supporting terminology assets. As an aside, an RC without the associated terminology is really bad news and not that useful.
- Forms & Domains – The business items, the items we deploy as part of our studies. I see CDISC giving us domains specifications as we know them today in an electronic form and based upon RCs. I do not see CDISC giving me forms for use in a study. I do see CDISC giving me example forms based on Research Concepts to show how the RCs can be used and deployed. The sponsor will need to develop the forms based on the RCs, use the CDISC domain specifications and develop their own domains (good old custom domains). So skills will be needed in using RCs, how forms and domains are built with them. This is a different skill set from creating RCs.
And then once we have all of that we can build studies. The big gain is that our studies now share underlying definitions. When we use an RC on a form and in a domain in one study we know it will match those used in previous studies and in the next ones. Setting up brings challenges but the rewards can be great.