Communications Forms (cForms, Letters)
Letter Forms facilitate standardized documentation while accommodating a stakeholder's requirement for a particular documentation format. The forms can be rendered in a print and fax-friendly format for easy communication (In Basket, email, eFax or print). The underlying templates can take advantage of SmartTools, allowing interactive charting (e.g., click-to-edit). Double data-entry is minimized because much of required information can be pulled from the patient's chart and presented to the clinician for final editing.
Documentation Use Case
A use case will clearly describe the documentation goal to be supported through informational interventions. It should include details of:
What is to be documented?
Scope of clinical topics
Who is doing the documentation?
Professionals and roles
Where the documentation is occurring?
What user input devices are available and easy to use in those locals?
Are there physical and/or temporal constraints?
When does documentation begin, possibly repeat, and end?
For what proportion of a provider's workload must this documentation be done, at what points during an encounter, and with what repeat frequency?
How do users currently document and what is done with the information?
Clinical utility of information - what clinical decisions, processes and/or outcomes can be affected?
Quality assurance/improvement use - when and by whom, with what feedback to users?
Regulatory requirements?
Other uses? How does the information need to be summarized to support clinical and/or administrative decision-making?
Documentation Needs Analysis
Provided with a clear use case, and access to its sponsors and subject matter experts, the builder can perform a simple documentation needs analysis, including consideration of the following questions:
Is structured data required?
Many documentation use cases include future use of captured information for reporting, quality improvement, decision-support or leveraging other Epic tools. This often presumes capture of structured data as a byproduct of the proposed documentation workflow.
Users may not explicitly identify their structured data requirements and so builders may need to discern these from the use case and present to the requestors for validation.
A structured data inventory should include proposed (Connect Care naming norm compliant) labels for each data point, together with details of the data type (e.g., text, numeric, date, etc.), context (e.g., patient, encounter), attributes (e.g., categories), need for comments and whether the information is static (captured at single points in time to support patient or encounter level determinations), dyanamic (frequently changing) or serial (what is important is how the data changes or trends over time).
The inventory should be thinned to just include structured data for which there is a demonstrable clinical need and a credible plan for use.
Can existing data be reused?
Many documentation requirements can be addressed by reassembling data that is available to capture as part of other workflows. Most obvious is demographic data. However, many elements of clinical history taking or examination are already supported with structured data.
An existing data point should not be reused simply because it has a suggestive label or description. It is necessary to confirm the clinical intent and use of the data to see that it matches and will be comparable to the new use case intent.
An existing data inventory should be grouped by where the information is stored, at a minimum distinguishing between database (e.g., ETP), flowsheet and Smart Data Element (SDE) types.
How must captured documentation be presented?
Are there specific documentation formats that MUST be used (e.g., government pdf files, regulated forms, etc.) to present captured information for a specific purpose?
Are there documentation metadata requirements that must be heeded in order for documentation to flow appropriately through system-to-system interoperability, integration or interfacing?
Are there accepted standards for required sections, titling, headers, footers or other elements of the documentation in communication tools?
Are there more than one ways that captured information is to be presented for different purposes or workflows?
Documentation Strategy Proposal
Once an information needs analysis is performed, it will become easier to suggest elements of a documentation strategy. This will acknowledge how information will be entered (e.g., dictation, voice recognition, keyboard, mobile device, etc.) and how documentation activities will be organized over person, place and time.
It is important to clarify which documentation elements are static, dynamic and/or serialized.
Proposed documentation strategy should provide a high-level summary of what was learned from the use case and needs analysis, together with a clear statement of what should, and should not, be expected from supportive informational interventions.