Application Metadata
From DOC
Application metadata is used to configure Tolven. In general, the features defined in this section are configured at runtime, that is, the server and the database are running while application metadata is loaded or changed.
Contents |
Account Type
Account Type is the basis for each Tolven application. An Account Type is represented as a row in a database table. Out of the box, Tolven provides two Account Types, eCHR (Clinical) and ePHR (Personal). You may notice that, technically, these configurations are very similar, often with just small differences that appeal to a different audience. For example, a blood pressure reading is identical between applications but may be presented in different ways. The "patient list" in the eCHR application is called Family Members in the ePHR application but otherwise they behave the same.
An AccountType and the structure underneath that account type is maintained by the system administrator.
Technically, the plugin configuration tolven-config/plugins.xml specifies which plugins to use and that includes application metadata. Tolven provides a prototype plugin called org.tolven.applications which can be used as a starting point for a specific project.
It is very common to buld application metadata by extension. For example, a specific account type might be established in one plugin and then any number of dependent plugins will apply extensions. For example, adding the "Body Mass Index" plugin extends the base applications to include the Body Mass Index assessment, computation, etc. Note: This plugin has elements that apply to configPhase1 (requires application server restart) and configPhase3 (does not require restart).
Account
A quick review of what an account is:
- Accounts are typically a clinic, department, service, practice, or family.
- An account will typically have multiple users
- One user can be a member of more than one account
- The behavior of an account is dependent on its account type (e.g. eCHR, ePHR).
- Tolven's strongest security boundary, including encryption-based security, is enforced between accounts. In other words, information in one account is not accessible from another account.
- Sharing data between accounts requires an "explicit action", by a user of the originating account. For example, if a user wants to authorize a network of emergency rooms to access a summary of their medical record, then that summary is sent to an account representing that pool of ERs. In this way, the owner of the data is not granting access to the data but in fact is giving a copy of the data to the ER network (accompanied by an audit trail of the action).
A user is either logged into a single account or is in the vestibule. The vestibule is where the user selects which account they wish to log into or where they can create a new account. Once the user logs into an account, their experience will be controlled by the configuration for that account. Switching accounts requires a password to avoid a nosy co-worker "backing into" someone's personal health record.
Updating From Account-Type to Account
The Tolven architecture avoids, where possible, imposing functional changes unilaterally on an account. (Security, login, and similar system-wide behavior is not included in this approach). For example, Clinic A might be ready to uptake a functional change on a different day than clinic B. Each can do so at time that is convenient to that account rather than a time convenient to the system administrator.
Technically, such an upgrade only involves manipulating database data, no software changes are involved. This is because the software is written in such a way that it honors the current configuration whether it is old or new. In other words, the software is upgraded when it is convenient for system administration. An account is upgraded (functionally) when it is convenient for the account administrator and thus the users of that account.
Menu Structure
The menus for a particular Account (or Account Type) exist in database tables. What this means is that if two or more Tolven installations are configured to reference the same database, then both installations will share the same metadata, menu structure, users and actual instance data. An integral part of this structure is the definition and selection of individual columns.
Tab
A tab entry in the menu structure represents a navigation point. Tabs form the basic navigation tree for the application. Internally, Tabs can go to ten levels deep, the Tolven-supplied style sheets only support four levels (Even use of four levels of menus is discouraged).
The number of items at any one level is not limited except by the real estate available on browsers. Tolven has found that ten items at any one level is about max. Additional menu items will "wrap" into an overflow area called "More".
Placeholder
A placeholder represents an instance of some entity such as patient or a specific observation. A placeholder is characterized visually by having a close button. In addition the actual contents of the placeholder display is controlled by a small xhtml snippet controlled by the MenuStructure entry for that placeholder. For example, a patient would typically display first, last name, gender and age.
Tolven automatically displays a copy of the placeholder title into the Caption bar of the browser to provide additional assurance that the user is looking at the correct patient.
Portlet
Portlets are small display that can be "stacked" into a single view. Each portlet is separately defined, queried and updated. Portlets are arranged into a grid pattern.
List
Lists define a collection of things. Tolven presents all lists as scrollable with no specific size limit. Each column to be displayed is specified in a child table to MenuStructure called MSColumn. Each entry in this table specified the MenuData value(s) to display, the column order, width, alignment, and any drilldown capabilities.
All columns are automatically sortable. A filter is provided automatically. (Rules determine which items are filterable by adding phrases (which do not have to be shown on the screen) to the MenuDataWords table. This makes filtering be words fast and efficient.
Wizard
A wizard is the form used to create one or more placeholder instances (patient, observation, allergy, etc). A Wizard often contains multiple steps which can be enabled or disabled. Steps can also be added during the wizard process. In general, a wizard will create a document which, upon submission, will be processed by the back end.
Each trim can define a specific form to be used to control it's data entry although it is most common for many trims to use a single generalize wizard form that can access the trim itself for specific selections, text, and values.
Drilldown
A drilldown is the read-only form used to display placeholder data. Prior to submission, the drilldown shows what the item will look like after submission. It also shows any errors, if any (see below). If the application reports errors, the wizard cannot be submitted.
Once submitted, the drilldown provides a view of the placeholder item and/or submitted document.
