EDM Model Objectives (3 replies and 2 comments)
Great post, Michael, thank you! Let's get the dialog started!
The original purpose of the model was truly as you described - to help people setup their new content management solution. However, eight years later I'm not sure how many people are really starting from scratch. Regardless of the chosen platform, vendor solutions are coming equipped with at least a starting point for submission management. Therefore, I think the model has two roles - 1) help vendors create a consistent starting point, regardless of the platform, and 2) help end users with suggestions on metadata they might want to manage and potentially folder structures as well.
My hope is that we can focus on improving the leveling of the artifacts to be more consistent across domains, similar to the TMF Reference Model with Zone, Section and Artifact. This helps promote item number 1 from above.
Secondly, your Shire example of misuse or lack of metadata is another key element that transcends search-based or folder-based approaches. Our metadata is not defined well enough to address the example you shared, and providing better examples and more robust lists of suggested metadata, along with associated controlled vocabulary examples, should help both vendors and end-users alike.
I'm also thrilled to see your point about structured content authoring, as I've been trying to push it with the team for a few years but to no avail. I think the industry is finally ready to embrace it, or at least much more than in recent years. Plus with products such as Author-it changing the game, I think the software world is finally approaching a state where it can provide the value needed without every using "XML" in a sentence.
Some of the changing objectives are related to advances in technology. Early EDMS systems mimicked a fixed file-share folder structure. That is changing as flexible hierarchic (even non-hierarchic) structures are available today. These are generally based upon structured metadata using standardized data values (or Controlled Vocabularies - CVs).
Objectives such as:
- Auto-populate Submission with Authored documents
- Merge In-licensed documents & M&As
All need standardized metadata, not simply a fixed structure for document organization.
This would suggest the EDM Reference Model needs to address standardized metadata...
I don't want this to become a discussion of metadata at the expense of the model, but here goes.
Metadata is a great idea. Indeed, the EDM should use the efforts of others, as, in my view, the submission is the keystone in the arch formed by other initiatives (TMF, CMC, IDMP, CDISC, etc). The problem is there are many metadata initiatives with conflicting use cases that generate conflicting and overlapping controlled vocabularies and metadata.
Here's an example. You want to tag a medicinal product indication using a CV. Depending on where you are and use case, you might use SNOMED, MedDRA, ICD, or some other CV.
There is currently a high-level initiative (I can't remember who's running it) to map these CVs so that they will be inter-operative. But this will take a long time.
Also, the only current nexus for many, but not all, of these initiatives is HL7, which might not address all the EDM needs. Or perhaps there is the potential for a greater integration with some of these initiatives, for different end results (messaging - HL7, content management - EDM).
To use metadata efficiently, and move toward structured content, we would need to review current metadata that might have an effect on EDM, as well as pending initiatives, to move this forward. As mentioned in the indication example, this is a necessary step and would also be a very valuable contribution to the community at large.
Perhaps what is needed is a metadata task force to review metadata and CVs.
I agree that we don't want to totally focus on metadata - but I also agree that it underpins much of what I think we're trying to do with the model. I think it would be useful to agree on a few primary use cases, and then look at the model to see where it needs adjustment/further development. No doubt metadata will be a big part of it.
So, getting back to the model.
One of the points identified in the discussion on 2 November was the idea of a "core" or idealized structure, and identify what metadata would be useful to add to the core for different lifecycle and use cases.
Is that a practical idea? If so, identification of existing or needed metadata sources is a high priority. If not, what can be done to add the idea of dynamism to the static structure EDM represents?
To me, it seems that many of the problems we are encountering with the model stem from this tension between the static and dynamic aspects of how documents behave in the real world.
Perhaps at this point, we make all efforts to get the latest version of the model out, and make plans to move dynamism into the model in the next full point release.
All - this post duplicates my recent email, as suggested by Steven, I'm moving the discussion here. (Assuming there will be discussion...).
Michael
All – just a follow up on one of my comments today. The question I find it hard to answer when asked is:
What is the purpose of the EDM model? When/why would I use it?
Possible reasons:
1) Setting up an EDMS "properly" – I think this relates to the "static" model we discussed
2) Managing lifecycle of documents and submissions – this would be dynamic aspects of the model?
3) Setting the groundwork for eventual content re-use. Very few companies seem ready to take this on as we discussed –but perhaps there are useful recommendations about what would facilitate this in the future without making any commitments to particular technology or process.
4) How to make integration of new documents (acquisitions/mergers) more efficient and more traceable.
Lots of other possibilities I'm sure.
Perhaps we could identify more clearly what our goals are and are not – and then we could identify paths into the model depending on which of these is of interest. To take a very simple example – if you're setting up a new EDMS and want to know how to structure folders/cabinets – look at this part of the model and consider these implications for other decisions you make (TMF?). If you have an EDMS but want to faciliate integration, you should consider these metadata objects – or this subset of metadata objects. Etc.
I'm not suggesting limiting the model so much as I am suggesting looking at making it more accessible for different users at different stages of evolution.
Here's something that came up not too long ago at Shire and is an example of one purpose that even established companies could benefit from:
The same metadata fields for documents were being used somewhat differently by different functional areas. (Document Name, Document Description). Some functions use those two for the identical data – other functions had standard nomenclature in one field and a longer descriptive title in the other. Reg Ops wanted a field that matched the eCTD leaf naming standard and wanted to use the Name field for this and transfer the contents of the name field to the description field – which would have caused confusion for those groups depending on Name for identifying documents. And something as simple as changing views in the EDMS for clinical users to see a different field to facilitate this change would have caused the tearing of the fabric of space/time and the breakdown of civilization as we know it.
Surprisingly though – there was no field in the system dedicated to this specific purpose – providing a way for Reg Ops to map to the eCTD naming – even for a company the size and age of Shire. And no one had layed out what the different "name" fields were, how they were used, who needed to see them in their daily view of the EDMS and which could be hidden for most users. So every function had made their own decisions about what to put in each field.
I think standardizing things like this could be one very valuable purpose of the model.
Perhaps we can have a goal of setting up instructions that say "if you want to do this, look here and here in the model" . And then structuring the model to facilitate that.
Whatdya all think?