This is the next post in my series of Do’s and Don’ts Healthcare IT. As we all know, some of our most important citizens live in rural settings, small cities, the countryside, or remote areas. These areas have smaller populations and less direct access to vital healthcare resources. In the past 15 years or so we’ve made some great strides in remotely accessible healthcare; these offerings, called telemedical tools, provide important clinical care at a distance. Here are some do’s and don’ts of telemedicine:

• Do use commonly available web meeting and online video tools bring expert caregivers anywhere. WebEx, GotoMeeting, Adobe Connect, Skype, and a variety of other “web meeting” tools used mostly in professional office settings and remote sales pitches are wonderful tools to connect caregivers in populated communities to their rural patients. A simple $30 to $50 per month account on the physician side with almost no direct cost for the patient is an excellent way to engage with patients. These kinds of web meetings can happen securely either at the patient’s home or patients can be brought into satellite offices with high-quality telepresence. Then, instead of waiting for days or weeks for a health professional to travel to an area or patients having to take off many hours or entire days traveling to experts in big cities, care can be given almost immediately with less inconvenience. Don’t assume that kinds of web meeting solutions are HIPAA compliant out of the box; however, do realize they can be made HIPAA compliant with appropriate protections.
• Do use medical devices for remote monitoring of in-home care improve clinical observations. While web meetings are great for basic primary care, it’s not perfect for elder care, long-term care, and other types of clinical requirements. There is a new class of devices that can put near-hospital-quality patient monitoring devices into patient homes and “beam” that data to monitoring centers that can watch for important events across many patients in different geographical areas. Toss in a nurse or other caregiver that can visit once a week or once a month to calibrate the devices and you can see how much more convenience patients can have and have their physicians, wherever they may be, have immediate access to their actual vitals and clinical status.
• Don’t assume that medical device connectivity will be fast or easy to do on your own — you’ll need something like Qualcomm’s 2net platform. 2net is a trustable, Class I FDA-listed, standalone gateway with an embedded cellular component that sends clinical data truly “in the cloud” without requiring local internet connectivity. Medical data can be sent from devices in the same way that e-books can be read on Kindle devices – using 3G cellular, from mobile phones, and software APIs.
• Don’t always send patients to labs; instead, take labs to patients with mobile imaging and lab specimen collections that allow remote reading and web-based report distribution. It’s difficult for many rural communities to have their own full diagnosticians but mobile imaging centers and lab specimen “kiosks” can do the X-rays, take pictures, and perform collections and then send the data electronically to large populated centers where they can be “read” and analyzed; the reports can be distributed via secure e-mail or other web-based applications to doctors in the rural areas or physicians remotely available and connected through web meeting or other similar tools.
• Do try and make behavioral health, mental health, and related care made more accessible. Veterans of our foreign wars are coming home with many problems that can be easily diagnosed with proper access and many of the veterans live in rural communities; while primary care and specialty care is difficult to get in smaller population regions, behavioral and mental health is even harder to access. Telemedical assistance through online chat, Skype-like video conversations, and secure online messaging can provide quick relief.
• Don’t leave patients on their own and encourage them to join online communities. Online community building tools allow populated city citizens to meld with their rural counterparts. Patients helping other patients is a terrific approach to extending care; sometimes what a patient needs is not necessarily a health professional but a curated session with fellow patients going through the same problems. Online, electronic, community tools such as PatientsLikeMe.com can connect geographic communities and bring them closer together without increasing costs or requiring anything more than a simple mobile phone or computer.

What do’s and don’ts would you add to a telemedicine strategy? Drop me a comment below.

I recently wrote, in Do’s and Don’ts of hospital health IT, that you shouldn’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A couple of readers, in the comments section (thanks Anne and DDS), asked me to elaborate mobile and mHealth strategy for healthcare professionals (HCPs) and hospitals.

A couple of the key points were:

• (Anne) how can you avoid making long-term mobile decisions at this point?  After all, hospitals that don’t steer their doctors are going to be managing whatever technology the doctors invest in, aren’t they?
• (DDS) the risk is that people will take this to mean that they shouldn’t move at all on mobile app platforms, and this would be a mistake. This is the perennial issue with health IT; if it’s not perfect, then wait.

The approach I recommend right now for mobile apps, if you’re developing them yourself, is to stay focused on HTML5 browser-based apps and not native apps. So, to answer Anne’s and DDS’s question specifically, no you shouldn’t wait to allow usage of mobile apps by anyone; but, if you’re looking to build your own apps and deploy them widely (not in simple experiments or pilots) then you shouldn’t write to iOS or Android or WP7 but instead use HTML5 frameworks like AppMobi and PhoneGap that give you almost the same functionality but protect you from the underlying platform wars. In the end, HTML5 will likely win and it’s cross-platform and quite functional for most common use cases. If you’re not developing the apps yourself and using third-party apps, then of course you must support the use of iOS native, Android native, and soon Windows native apps on your network.

So, from a general perspective you should embrace mHealth but do so in a strategic, not tactical manner. Here are the most critical questions to answer in a mHealth strategy — it’s not a simple one size fits all approach:

• How will you allow doctors’ or patients’ own devices within your hospitals / organizations — simply by providing connectivity and wireless access on the production network or some other means?
• How will you allow doctors’ own devices to connect to hospital IT systems?
• How will you extend hospital IT systems via hospital-owned mobile devices?
• How will you allow the hospital or organization to “prescribe” the use of apps to patients and track the usage of apps?
• How will you approve or deny the use of certain apps that may not meet FDA regulations if they get close to MDDS or Class 1/2/3 devices?

If there is interest in this topic, I will expand on my list of Do’s and Don’ts — mHealth is a very complex topic and requires a good strategy. Just saying that you allow the use of mobile devices like smartphones in your hospital is not an mHealth strategy.

In case you haven’t seen it, MU attestations data is now available on Data.gov and it includes analyzable vendor statistics.

The data set merges information about the Centers for Medicare and Medicaid Services, Medicare and Medicaid EHR Incentive Programs attestations with the Office of the National Coordinator for Health IT, Certified Health IT Products List. This new dataset enables systematic analysis of the distribution of certified EHR vendors and products among those providers that have attested to meaningful use within the CMS EHR Incentive Programs. The data set can be analyzed by state, provider type, provider specialty, and practice setting.

The data set does not include dollar amounts or the difficulty of attestation (e.g. how many times it took to pass). I’ll try and find out if that data might be available in the future. It’s also unclear whether the provider counts were broken up into each line (meaning one provider per row) or if multiple providers were aggregated into lines (meaning multiple providers were grouped).

The dataset is available now on Data.gov at http://www.data.gov/raw/5486 and is worth checking out. Since the file has been downloaded over 75 times, it’s clear some of you already know about this so if you’ve done some analysis with it; if you’ve done any analysis or posted results please drop me a note below so that everyone can benefit.

Last year I started a series of “Do’s and Dont’s” in hospital tech by focusing on wireless technologies. Folks asked a lot of questions about do’s and dont’s in other tech areas so here’s a list of more tips and tricks:

• Do start implementing cloud-based services. Don’t think, though, that just because you are implementing cloud services that you will have less infrastructure or related work to do. Cloud services, especially in the SaaS realm, are “application-centric” solutions and as such the infrastructure requirements remain pretty substantial – especially the sophistication of the network infrastructure.
• Do consider programmable and app-driven content management and document management systems as a core for their electronic health records instead of special-purpose EHR systems written decades ago. Don’t install new EHRs that don’t have robust document management capabilities. Do consider EHRs that can be easily integrated with document and content management systems like SharePoint or Alfresco.
• Do go after virtualization for almost all apps – as soon as possible, make it so that no applications are sitting in physical servers. Don’t invest more in any apps that cannot easily be virtualized.
• Do start looking at location-based asset tracking and app functionality; your equipment should be aware of where it’s physically sitting and be able to “find itself” and “track itself” using location-based awareness. Don’t invest heavily in systems that can not support location-based awareness (like potentially allow or disallow logins based on where someone is logging in from as well as enable / disable certain features in applications on where logins are occurring).
• Do start implementing single sign on and common identity management with CCOW integration. Don’t invest in any systems that cannot meet common identity or SSO requirements.
• Don’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A platform that looks strong today may be weak tomorrow and become legacy quickly; however, HTML5 is not going anywhere and will be ultimate winner of the next 15 years just like HTML4 is the winner from 1995 to now. Do start investing in HTML 5 and CSS3 and away from HTML4. Don’t install any more apps that require IE6/7 or older browsers and don’t invest in systems that don’t have HTML5 in their roadmaps.
• Don’t write applications on top of legacy EHR platforms; write applications with proper HL7 connectivity and platform independence. Most EHR platforms are using technologies that are either ancient or need to be replaced; by integrating deeply but remaining independent of their technologies you’ll get the best of both worlds.
• Don’t buy any medical devices from vendors that don’t have a deep and thorough medical device to healthcare IT enterprise connectivity strategy. If a device doesn’t have wired or wireless TCP/IP access, doesn’t have data export or HL7 connectivity is not worth purchasing.
• Don’t buy any thick-client applications that do not have thin-client “remote viewers” available.

One of the most important activities you can undertake before you begin your EHR implementation journey is to standardize and simplify your processes to help prepare for automation. Unlike humans, which can handle diversity, computers hate variations. Before you begin your software selection process, get help from a practice consultant to reduce the number of appointment types you manage, reduce the number of different forms you use, ensure that your charting categories (“Labs”, “Notes”, etc.) don’t look different per patient type or physician, determine how you will manage medication lists and problem lists across the patient population, and deal with how you’ll manage paper in your digital world.

If you spend even just a few hours a week doing the prep-work before you buy any software, you will be better prepared in your selection process. Without some level of standardization your EHR implementation will either fail, be delayed, or have many unhappy users; the more you can standardize and simplify, the more likely you will have a successful outcome. A strong project manager with authority to make decisions will be the difference maker in the simplification process.

To help you with your workflow assessment and standardization efforts, check out the The Agency for Healthcare Research and Quality (AHRQ.gov) Workflow Assessment for Health IT Toolkit. Even if you’ve done workflow assessments before, the toolkit is worth checking out.

As most of my regular readers know, I work as a technology strategy advisor for several different government agencies; in that role I get to spend quality time with folks from NIST (the National Institute of Standards and Technology), what I consider one of the government’s most prominent think tanks. They’re doing yeoman’s work trying to get the massive federal government’s different agencies working in common directions and the technology folks I’ve met seem cognizant of the influence (good and bad) they have; they seem to try to wield that power as carefully as they know how. Since most of you are in the technology industry, albeit specific to healthcare, I recommend that you learn more about NIST and the role it plays – they can make your life easier because of the coordination and consensus building work they do for us all. I, for one, was thrilled when NIST was picked as the governing body for the MU certification criteria. These guys know what they’re doing and I wish they got more involved in driving healthcare standards.

A few years ago NIST came up with the first drafts of the seminal definitions of Cloud Computing; they ended up setting the stage for communicating complex technical concepts and helping making “Cloud” a household name. After 15 drafts, the 16th and final definition was published as The NIST Definition of Cloud Computing (NIST Special Publication 800-145) in September. It’s worth reading because it’s only a few pages and is understandable by the layperson. No computer science degree is required.

Yesterday I was speaking to a senior executive in the EHR space and we had a great discussion on what healthcare providers are doing in terms of cloud computing and how to communicate these ideas to small practices as well as hospitals. It reminded me of the numerous similar conversations I’ve had with other senior executives we serve in the medical devices and other regulated IT sectors. In almost every conversation I can remember about this topic over the past couple of years, I had to remind people that NIST has already done the hard work and that we can, indeed, rely on them. Most of the time the senior executive was unaware of where the definitions came from so I figured I’d put together this quick advisory.

My strong recommendation to all senior healthcare executives is that we not come up with our own definitions for cloud components – instead, when communicating anything about the cloud we should instruct our customers about NIST’s definition and then tie our product offerings to those definitions. The essential characteristics, deployment models, and service models have already been established and we should use them. When we do that, customers know that we’re not trying to confuse them and that they have an independent way of verifying our cloud offerings as real or vapor.

Below I have copied/pasted from NIST 800-145 their key definitions. Imagine how many debates you would avert with technicians at clients when, during conversations with a client, you communicated some of the following information first, showed them how it was a “standard definition” and handed them a copy of the publication, and then mapped your offerings and discussions to the different areas. Your sales teams and the marketing teams would appreciate the clarity, too.

Note that you do not need to map every offering you have to every definition – just start mapping the obvious ones and then figure out how you can communicate the “gaps” as being not applicable to your products / services or if those gaps will be filled in the future as part of your roadmap. Treat these definitions as canonical but not inclusive – meaning that just because your SaaS offering doesn’t fit every essential characteristic doesn’t mean that you’re not “cloud” – it just means partially cloud.

If you’ve got questions about how to map your product offerings, drop me some comments and I’ll assist as best as I can.

Here are the key definitions from NIST 800-145, copied directly from the original source:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability¹ at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Service Models:

Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure². The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.³ The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models:

Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Productivity loss and workflow disruptions are commonplace as our industry gets on the Meaningful Use bandwagon and is starting to adopt EHR systems at a slightly more rapid pace than in previous years (things aren’t really as rosy as many think, but the pace is picking up). The reason we have productivity loss is that we focus changing the behaviors of our most expensive resources too early in our automation journeys – we go after doctors first.

My experience, and some basic math, shows that if you want a physician to be more productive you first make sure their supporting staff have the tools they need to reduce the physician’s burdens. Only after you’ve optimized those around a physician do you then go after improving the physician’s productivity.

According to research done by GE, you need (on average) about 5 supporting resources per physician to help manage patient records and a bit more to support patient care. What if we focused on building software and systems for optimizing the work of the 5 resources around the doctor first? What if we offered more capabilities for patients, with proper verification and validation by a professional through simple tools, to self-manage their data directly in EHRs? Not just through portals, but real collaborative care management tools.

Physicians are highly trained, which means they have years of things to “unlearn” if you change their workflows and they are (generally speaking) well paid which means if you any mistakes and disruption in their workflows is far more expensive than for supporting staff. Of course, the opposite is also true: if you get the automation right, the return on the investment is certainly worth it; the problem is, while ROI might be high, the risk of loss is also high.

This advice may seem obvious, but the architecture, design, user experience, and implementation of existing health IT apps don’t always heed it. I’m sure we all see, over and over again, that many apps are being written to increase documentation and data entry requirements by doctors – instead of using system integration, medical device connectivity, and other simple technologies like worklist management to reduce the workload.

As I mentioned above, productivity loss and workflow disruptions are commonplace with EHR implementations – drop me a note below about how you think vendors should change their products to make things better.

Earlier this year, when I traveled to Denmark to review some of their Health IT companies, I spent a couple of days with Joe Ternullo of Partners Healthcare and their Center for Connected Health. Joe is a gentleman in the classic sense of the word and one of the nicest people you’ll ever meet; I was amazed at how connected he was to outcomes-driven health IT and quite impressed with his knowledge of the industry.

Joe kindly invited me to speak at Partners Connected Health Symposium as the kick-off debater on a topic entitled “Current Approaches to Patient Self-Management Do Little to Improve Quality or Lower Costs.” He convinced me to go outside of my comfort zone and say that I agree with the position that patient self-management (basically using computers, smartphones, and software to self-manage their healthcare) doesn’t really improve quality or lower costs.

Given that I’m “The Healthcare IT Guy” I am accustomed to taking the opposite position (that the act of patient self-management usually does enhance care quality and reduce costs) but I figured I’d have fun debating Dr. Joe Kvedar on his home turf and in his area of expertise even if I was taking an unfamiliar position. Dr. Kvedar, a most congenial fellow, took it easy on me and the debate went well.

Joe Ternullo asked me to take the position against the premise of the Connected Health Symposium to make sure we left no stone unturned in evaluating the real benefits because we need to critically appraise patient self-management.

The video of our debate is available here. It was a gentlemanly debate focused on raising issues and provoking thought but I hope you’ll take a look and let me know which points you agree with and which side you think “won”

In working with Cynthia Bouthot, our accomplished multi-talented moderator, and the organizers of the Symposium, I learned quite a bit about both sides of the argument. Cynthia kept us on topic and on time and she did great teeing up some important questions.  I’m grateful that Joe Ternullo invited a geek like me to do the debate with an eminent physician and thankful to Dr. Kvedar for letting me share the stage with him. Hopefully they’ll ask me to come back next year.

Leave me some comments below on what you thought about the debate.

I met researchers from Macadamian, a global UI design and innovation studio that has been doing some great work in the health IT usability space, at the recent EHR Usability Symposium held at NIST a couple of months ago.

I was immediately impressed by their work so when they asked me to work with them on presenting NIST’s new Usability Criteria for Health IT and EHR Software document, I welcomed the opportunity.

Please join me as I moderate a webinar in which Macadamian’s experts review the usability criteria that are expected to be enforced in the next stage of Meaningful Use. While many healthcare IT vendors say they already put careful thought into their software design, they are often unaware that they are making serious mistakes that can slow down a healthcare team’s workflow and even put patient safety at risk.

Information on the upcoming education session, which will focus on debunking some serious myths, is below.

Registration URL: Preparing for NIST EHR usability criteria – 9 Myths of Effective Healthcare Software Design

Date: Nov. 30, 2011
Time: 1:00 pm CST / 2:00 pm EST
Location: Your Desktop

If you’ve got some questions or suggestions for me or the folks at Macadamian, please share them below. We’re going to want to make sure that the session is full of actionable advice.

Complex healthcare IT projects like EHR implementations, ICD-10 migration, and related IT initiatives require sophisticated change management practices and policies. Given the people-centric nature of policy development, those of us in IT usually assume that change and policy management can’t be automated, usually to our detriment. To help understand how that’s not quite correct, I reached out to the developers of PolicyStat, which provides policy and procedure software for hospitals, labs, outpatient clinics and integrated health networks. I asked them to help explain what “policy and practice software” is, why it’s useful, and what the options are. Here’s what they said:

Manual, repetitive, time-consuming processes in information management have somehow survived in many healthcare organizations through 2011. Behind-the-times hospitals are using three-ring binders to store their hundreds or thousands of policies, procedures, guidelines, protocols and checklists – all of which must be reviewed and approved on a regular basis in keeping with compliance. Information that should guide the care given to patients is not even consulted in many cases, either because the staff member cannot find a particular policy or because he or she does care that it exists. Hospital administrators and others at the top might care about the problem, but they “have bigger fish to fry” in the health IT world in dealing with EHRs and other more popular IT systems. Systems for managing these policies, procedures, guidelines, protocols and checklists fall to the bottom of the list.

EHRs are a hot topic now, and they should be. Healthcare is taking drastic turns, and it’s not possible to fix every problem at once. But just how big of a deal are policies and procedures? To understand the magnitude of policy and procedure management, take a look at two examples below of facilities – one large, one small – which have already implemented a policy management system (please note that “policies” also includes procedures, guidelines, protocols, etc).

Large short term acute care facility with 1,000+ beds
5,198 active policies which must go through annual approvals
2.08 average approval steps per policy (ranging from 1 – 4 steps)
4.38 average days per step (ranging from 1 – 258 days)
3,763 – 10,961 monthly policy searches (data below are monthly averages from October 2010-11)

Small critical access hospital with 25 beds
1,450 active policies which must go through annual approvals
3.27 average approval steps per policy(ranging from 2 – 4 steps)
15.8 average days per step (ranging from 2 – 23 steps)
0 – 238 monthly policy searches (data below are monthly averages from October 2010-11)

If you do the math, the large hospital goes through an overwhelming 10,812 approval steps per year, with each step lasting more than four days. The small facility goes through 4,742 approval steps per year at an average of almost 16 days per step. Considering the time it takes for an approver to search for the document requiring approval, make changes and email it to the next person, it is obvious why manual policy approvals are so time consuming. Furthermore, it takes substantial time for a caregiver to search for and locate the needed policy or procedure while also attending to patients.

A policy management system helps a hospital or healthcare facility in two ways: it reduces manual processes such as policy approval routing, and it helps caregivers quickly and efficiently find and consult information. By using powerful software to manage your 1,000+ policies and procedures, your hospital can save money and provide the best patient care possible.

Let’s assume you have decided to implement a policy management system for your organization. Maybe the person in charge of policies has run into problems with compliance and needs a better system to track expirations. Maybe your administration has been flagged about the major inefficiency of the current process. Or perhaps you have an EHR in place already and want to start your next tech advancement. Whatever the reason, you will want to explore your options first.

Types of Policy Management Systems

There are three main types of systems available to you, each of which requires different levels of IT involvement: a legacy document management system, a hybrid document management system and a web-based content management system.

Legacy Document Management

Description: Lack of system; shared drive/intranet which stores native files such as Word or PDF

Pros: Infrastructure already exists, so IT staff resources are not required for development; does not require hardware or software (besides MS Word); users are familiar with using shared drives.

Cons: Versioning of documents and workflows are manual; lacks audit trail; lacks full-text searching; lacks visibility into expirations on policies; makes sharing/coordinating across facilities difficult; makes it hard to standardize documents; requires users to download documents to MS Word to view and edit.

Tips for implementing (or restructuring) a legacy document management system:

1. Create clear ownership responsibilities around departments.
2. Define standard approval workflows and folder structure.
3. Define and enforce consistent naming conventions which include author, date and policy area.
4. Back up older versions but store them away from the typical users’ view.

Hybrid Document Management

Description: Sharepoint or other application which has workflow functionality and stores native files such as Word or PDF; may use a Flash or Javascript plugin

Pros: Facilitates defined workflows; automates workflow routing; sends reminders for expiration; keeps track of an audit trail; makes searching easier; allows for security and access control.

Cons: Requires set-up and training; lacks context-sensitive searching; makes sharing/coordinating across facilities difficult; makes it hard to standardize documents; requires users to download documents to MS Word to view and edit.

Tips for implementing a hybrid document management system:

1. Ask individual department owners to organize their policies before implementation.
2. Agree on and create a standard document template.
3. Use naming conventions to make searching as intuitive as possible.
4. Push as much interaction into the system as possible.

Web-Based Content Management

Description: Completely web-based application with no software/hardware or plugin to install

Pros: Allows for editing/collaborating within the browser; returns relevant search results almost instantly; does not require software or hardware; available from mobile devices and from home; lets system admins make site-wide changes at once; enables sharing/coordinating across facilities.

Cons: Requires upfront implementation and training; requires initial research to find the most cost-effective system.

Tips for implementing a web-based content management system:

1. Standardizing your entire policy library can be a considerable task if you are not organized. Find out how much of the workload falls on your organization before choosing a system/provider.
2. Review system status regularly (how many policies are expired).
3. Encourage ubiquitous access (mobile devices).
4. Take advantage of all features, i.e. use notifications feature instead of emailing.
5. De-centralize workload for approvals and policy revisions by assigning owners to policy areas.

Restructuring or implementing a new policy management system requires some effort from all departments – IT, nursing, infection control, compliance, risk, etc. Make sure your authors, editors and approvers are all on board before making a decision. You might be surprised by their level of enthusiasm for getting a better system in place.