Sharepoint Pros?
-
@Carnival-Boy said:
I was hoping for a slightly more hi-tech answer!It's a tough one because the data is presumed to not exist yet. In theory you can pull some data from file names, folder locations, permissions or something and then make a script to interpret that. But many companies would not have that data even in those ways. It's a tough one as the new system has so much more power than the old, but to leverage it data that didn't exist before has to be added to get the huge leap forward.
-
-
A quick Google suggests FCI is the way forward, but I need to look into it more.
-
I would be interested to know the results. Just to avoid confusion, as it happened to me, FCI is File Classification Infrastructure. Got a guide on doing this, but not sure how meta data is handled on this.
-
when you say add metadata to files, what are you talkign about?
-
@hubtechagain said:
when you say add metadata to files, what are you talkign about?
At the highest level: "Data about your files."
At a practical level it is like "tagging" your files. It is based on lists in Sharepoint. So you have some lists built in, such as the "owner and the editor" of files since the users list is part of Sharepoint. You could add a list of departments, topics, regions, offices, events, customers or similar to use to add data about a file. Pretty much anything you care to track.
-
So I will give a practical example. NTG uses Sharepoint. NTG is an MSP and has customers. NTG's Sharepoint site has a "list" of our customers that is stored in SQL Server via Sharepoint. In the customer document repository we made it mandatory for someone saving a file there to record the associated customer to which a file is referencing when saving the document. Basic metadata like the author of the file and the date in was created are always there, just like on a normal filesystem.
Because every file in this document repo must have a customer associated with it, anyone looking for data on that customer "ABC Corp" can just do a filter on that customer and only that customer's files are displayed. It's better than folders because it is flexible and not tied to a single detail. Sure we could do this for one item, one time using a folder structure.
But what if we want a second piece of metadata associated with the file? What if we wanted to only see Word Docs or OneNote files? What if we we had metadata telling us that a file is about customer configuration data or their SLA guidelines or billing history or documents related to taxes? With metadata we could choose to filter on any one or any number of these in ways that folder structures cannot and make it faster and easier to navigate large amounts of files.
-
Is metadata the same as Sharepoint columns? So, for example, I've created a new document library to store vendor invoices. I've added a column to that library called "Vendor".
-
@Carnival-Boy said:
Is metadata the same as Sharepoint columns? So, for example, I've created a new document library to store vendor invoices. I've added a column to that library called "Vendor".
Metadata is stored in lists which are database tables which are made of columns, but I wouldn't call them the "same" as the database stores a lot of stuff, only some is used as metadata and used as that only some of the time. But if you have a library called Vendor and you have a list of vendors stored in a list in the database and you are applying that list as a reference to a file, when used there it is metadata.
-
This is a fundamental change to the creation of documentation.
Like posting here on SW (or most forums these days) we can add tags. It's something I rarely do, and instead Scott follows me around like a kid with a cold and his parent wiping his nose.
The need to add this additional information is obviously very helpful when you're searching, assuming you've added the correct tags/metadata, but now you've also added more time that it takes to create/save that document.
I was trying to understand why my physicians (and medical staff) hated EHRs - it's because it truly required about 2-4 times the amount of documentation than paper charts did. There were two reasons for this. 1) things that we should be been recording were just being skipped - OK this is a win for EHR even though the non recorded data clearly didn't hurt us enough in the past to make us change to ensure we recorded it, 2) EHR added many new required pieces of documentation we didn't worry about/need in the past.
We went from having 1 Provider to 1 medical assistant, to needing 2 medical assistants per provider while in clinic. So now not only are we paying for the software (and infrastructure) we're paying for a lot more employees.Which ties back into Scott's comment
@scottalanmiller said:With 10K files, easiest way is to hire an old fashioned data entry clerk to do it for you
-
@Dashrender said:
This is a fundamental change to the creation of documentation.
One of the important SP features is that you can make some of the metadata mandatory rather than optional. The user can't save the file until they fill in the metadata.
-
Now don't get me wrong - I love the idea of moving away from the old folder structure, I still loose things in there.
Google is taking the same approach with photos. The idea is a single 'folder' of everything. Then they add the metadata for you (who's faces are in each picture, where was it taken, when, etc) then you search for what you're looking for.
-
@scottalanmiller said:
@Dashrender said:
This is a fundamental change to the creation of documentation.
One of the important SP features is that you can make some of the metadata mandatory rather than optional. The user can't save the file until they fill in the metadata.
How does that work with regards to locally installed Office apps?
-
@Dashrender said:
I was trying to understand why my physicians (and medical staff) hated EHRs - it's because it truly required about 2-4 times the amount of documentation than paper charts did. There were two reasons for this. 1) things that we should be been recording were just being skipped - OK this is a win for EHR even though the non recorded data clearly didn't hurt us enough in the past to make us change to ensure we recorded it
Nothing more encouraging than medical staff that don't want to record important patient data
-
@Dashrender said:
We went from having 1 Provider to 1 medical assistant, to needing 2 medical assistants per provider while in clinic. So now not only are we paying for the software (and infrastructure) we're paying for a lot more employees.
Is that a permanent need or just temporary until things are caught up?
-
@scottalanmiller said:
@Dashrender said:
We went from having 1 Provider to 1 medical assistant, to needing 2 medical assistants per provider while in clinic. So now not only are we paying for the software (and infrastructure) we're paying for a lot more employees.
Is that a permanent need or just temporary until things are caught up?
It's been 8 years since we went live with our first EHR and we still have them. I'm saying permanent. Though we have some recent management changes - who knows.. they could do some reorg'ing and we might see some change.
I personally don't think we need a full 2 MA's to 1 Provider, we could get away with 3 MAs to 2 Providers, but I'm an outsider looking in who's been told to stay out of it.
-
Probably like @Minion-Queen and I sharing an assistant. We could probably get away with one, but it's cooler to each have one.
LOL
