The following specification, produced by South Central Los Angeles Regional Center shows the basic POS Routing workflow. This will provide access to the POS, once created, by various users, automatically by creating entries in their 'To-Do' lists. A number of users can be specified for notification during routing and will provide for sign-off or rejection by specified persons.
Case Management in recent years has expanded its scope of functioning to include access to its data by consumers and vendors. While this has been on the radar and certainly on the wish list of Regional Centers for many years, and while some functions exists today, there remains a dearth of comprehensive functionality.
This trend towards expanded access, when fully realized, will have many benefits. It will enhance the amount and integrity, and therefore the value, of information collected. It will give users a sense of participation and control of their own wellbeing as well as providing a greater level of transparency. The enhanced communication will facilitate the conduct of case management and ultimately improve the delivery of services and supports to the consumer.
Sharing information in this manner is of course not exclusive to the social service space. Search engines, for example, collect data during their use. While this is obviously to the commercial benefit of the search engine provider, the user benefits as well by experiencing, among other benefits, faster and more focused and individualized search results. Kea has embarked on a project to provide greater access to consumers and vendors via web portals.
The initial, preliminary design elements are presented here. It must be noted that the idea of portals into regional center case management systems and databases has existed for almost as many years as the development of those case management systems. We will borrow from the many existing systems and requirements specifications generally published and available. Our belief is that this will insure the completeness and applicability of the program for our users by broadening the scope of its functionality and its facility for later enhancement.
Kea-Live has many inherent features that will facilitate development of portals. We will leverage this functionality and structure which will result in an easier and faster implementation and a more efficient interface to Kea-Live's database. For example, several existing features make it possible to accommodate both consumer and vendor access through one portal rather than developing two separate portals. For one thing, Kea-Live already includes a permission based system that can define what a user can access, modify or report on. Access by a consumer and vendor, therefore, would require only a change in the permission structure of the user. What the user sees or is capable of modifying, and perhaps downloading, is defined by their overall permission structure.
Once a user's permission structure has been created, accessing the portal by external software can be accomplished. The external part of the portal will be separately executed. This is desirable, for example, with vendors. The portal software executed by the vendor will be separate, but have the same look and feel as Kea-Live's UI (user interface). The two programs, Kea-Live and Kea-Portal, will therefore be dependent on each other. This has the benefit of added security, since the Regional Center, which houses the database, can exercise complete control of access.
For Regional Centers, Kea-Live is generally housed at their facilities. Security, therefore, in large part is their responsibility. The software will provide as much assistance in terms of flexibility and ease of integration as possible and practicable. And since the Kea-Live database already provides elements of security such as encryption of the database as well as data transmissions, most of the security issues will fall in the area of network access methods, hardware firewalls, etc.
There are three types or modes of access; Display which includes access to reports; Modify which includes entry of new data, and Delete. The type of access any user has is defined by the user’s overall permission structure which includes several elements. Virtually all consumer specific data may be made available as well as reports and forms.
This design provides a virtually unlimited number of definitions of access. Consumers, parents, medical professionals, and vendors, can each have different definitions. Each user may have a specific set of forms and reports that may be accessed which may be different from another user. And these definitions may be changed at any time by the administrator(s) of the system at each agency.
An optional ‘Change Request’ process will exist so that modifications made by users must be submitted preliminarily and authorized before actual database changes are effected.
In addition to access of the consumer database, a user may submit a request to include external data. For example, medical reports may be submitted that will be appended to the consumer’s records. This data can be included in the Kea-Live database or may be routed for inclusion into the agency’s document repository.
The system will maintain records of logins and data modifications so that the agency can obtain the status of the database and of the portal. Reports will provide status and audit trails. Management oversight will include the authorization of the optional change requests should they be implemented. Future reports can analyze the portal's use and effectiveness which will assist in defining modification of permissions, implementation of enhancements, or removal of certain access functions.
Most pages on Kea-Live have text that are part of the system, not user entered data. Generally, this text is termed 'metadata'. The dictionary defines metadata as "data about data". Field labels, column headings, and messages are metadata and this is the text that you can maintain in Kea-Live through the wiki processes.
The wiki processes are only available to users that have the proper permissions as assigned for your agency. More details on the entry process, permissions, global labels and other details will be provided when the wiki functions are implemented on Kea-Live.
Like so many other forms of printed material, software user manuals have been replaced by on-line documentation. And the content can take many forms, all made possible by digital devices that use the Internet and Browser technologies to deliver content. Take for example the Kindle and all the devices that have subsequently been developed that are replacing paper books and other publications. This is because content delivered over the Internet and presented on disparate digital devices is considerably easier to use and provides functionality not possible with the printed page.
History has taught us that except for a user manual’s initial use, users rarely reference them again, let alone read them as part of their training. Product makers realized this long ago and typically included 'Quick Start Guides' or 'Getting Started' pamphlets. Those instructional materials may even lead to additional online documentation and 'Getting Started' is often just a link to the producer's website.
Kea Systems has gone a step further by incorporating documentation and descriptive information into the web pages using a generic, wiki interface. Using Wikipedia as our inspiration, to insure that the content remains useful and current, our Wiki Page Help and Wiki Field Help provide a similar, user modifiable experience. That is, given the proper permission, a user can add, modify, or completely replace this content.
These posts are intended as general, functional overviews. They are not detailed nor are they specific to any agency. But a user who has permission, typically the system administrator, can use the wiki facility to change the content of all page and field help content, and create a unique help system customized to your agency.
Data entered in many fields in Kea-Live are contained in drop down lists. Many of these lists should not be changed, For example, when a field contains a number code which must be within a specific range such as 1 to 5 because it represents a standard, user specified 'grade'. Obviously, one should not change an entry in the table and make 3 a C. On the other hand, it might be different for another agency who uses the scale of A, B, C, D, and F. Or a third agency might use a grading system of 1 through 10. This is easily changed with the wiki process.
Most drop-downs will have a blank as the first entry. This should be retained when possible and is the right choice when no data is to be selected. It may also be desirable to use ‘Unknown’ or ‘N/A’ in place of or in addition to a blank entry.
Not all agencies use the same terms. For example, one agency may use the term 'Case Manager' while another uses 'Service Coordinator'. Your agency may use 'Client' while others may use 'Consumer' or 'Student'. The wiki function will allow you to change these various text elements to meet the needs of your agency.
The Label Wiki is primarily used to change field labels throughout the system. It is also used to change column labels on lists, menu items, and other text items as described here. Some labels are considered 'global' labels, that is, very common terms like ‘Client’ that typically appear on many pages. When a global label is changed on any page, it will be changed on all pages where it appears. When using the wiki interface, the global labels will be color coded so that they are easily identified. Other examples of such labels are 'Consumer', 'Case Manager', 'Date', etc.
When label wiki processing is initiated, and you position the cursor on a label, another window will appear that shows the label’s default and current value. You may edit the current label or restore the default. Column headings are modified in the same manner.
You should experiment with a few fields on a few pages and/or tabs before making wholesale changes. The strength and simplicity of the system is this: if you make a mistake, you can easily go back and fix it. Also, on each page, an icon on the task bar will allow you to reset all labels on the page to the default values. While the reset is for the current page, it is important to remember that global labels will affect many pages.
System messages are displayed for informational purposes or because an error has occurred. They tend to be very general on Kea-Live but your agency may want to provide more specific or additional information in these messages. Unlike the Help, Drop-Down, and Label Wikis, when the Message Wiki is invoked, all messages are displayed and can be individually selected for modification. Because it is important to know the context within which the message is displayed, only messages that would appear on the current page are displayed and can be changed.
Service coordinators have many functions with multiple processes that are performed sequentially.
Most case management software has the functionality, some have good documentation, help, and/or
tutorials. Some, have the functions and to a certain extent, enforce the step by step. Unfortunately,
few have it all.
Users, most of the time, understand and can handle the component functions. But often they don’t fully
comprehend or follow the desired step by step process, particularly when they are new to the job or
software. Again, software typically provides the functionality but in most cases, must be supplemented
by costly training sessions, rarely used or outdated documentation, and often, time consuming oversight
functions, reports and audit reviews. The best solution is of course training, however, the downside to
training alone is that you place institutional knowledge in people, rather than easily accessed system.
If users are tickled by software to perform the initial step of each function, and then are guided through
the process with reminders, ticklers, messages, etc., to perform the step by step, case management
would be easier, more efficient, and compliant. The step by step would be enforced as necessary by not
allowing execution of component functions until pre-requisites were completed.
If Scenarios were applied to include all of the above, compliance, of course would be enhanced, if not
totally satisfied; and the processes would be performed quicker and with less errors and omissions.
Training would be much easier because the emphasis would be on a single function, Scenarios, instead
of many disparate functions, often complicated and considerably different. The details or steps in each
function or process could be contained in the Scenario – that is, ‘System Knowledge’ rather than
individual people knowledge. Consistency would be inherent in the Scenario instead of the often
occurring “Here’s how I do it” system.
And if each agency could define their own Scenarios, through an intuitive, administrative process, we
would have something rather rare or in fact unique. Of course, there are other systems, not necessarily
in social service that have this functionality. But they are rare.
Here are some technical elements that would be needed:
Scenario would have the following available for inclusion:
Posts are grouped into the categories listed above. Within each category, the latest Posts are listed first
and there are a maximum of 10 posts per page. Use the navigation arrows to move from page to page.
Some posts are in more than one category. If you click on a Post Category, only the Posts in that Category will be shown in the content area to the left.
In all categories, you are welcome to enter comments. Posts other than Articles and Profiles, are part of the overall training and support of Kea-Live. After initial training, these posts, combined with page and field help, make training in large part, self guided.