Documentation Techniques
Documentation is the process by which clinicians record health observations, assessments or plans so that they can be shared with other members of the healthcare team. The Epic toolkit provides diverse ways to support documentation activities. Builders are often asked to address a particular documentation need through adaptation or development of tools for capturing data, representing data in readily understandable ways, and incorporating it into routine or required communication objects.
Builders are advised to start with a clear "use case" that describes the clinical need together with how informational interventions should help... remembering that successful documentation will depend on myriad other factors. These include end-user belief in the importance of the documentation task, as well as effective training, change-management, feedback and ongoing support. The builder can then recommend use of one or more documentation techniques and tools.
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.
Documentation Tool Selection
One or more documentation toolsets can be used in the build of a solution addressing a specific use case.
Static Structured Data
In general, static structured data is best captured using tools that optimally manage Smart Data Elements (SDE).
SmartForms, for example, provide maximal flexibility and user-interface features to promote consistent capture of the right kind of information. Rules and scripting can be used to conditionally present users with capture options depending upon what has previously been captured.
Dynamic Structured Data
Where there is less need to capture enduring data, and more need to generate very specific document objects (e.g., standard government pdf that cannot be accepted in any other format by the requiring organization), E-signature Templates can be used to insert SDEs (captured with SmartForm user interfaces) to precision document templates.
Less exacting presentation requirements can be addressed with SmartForm and SmartText combinations.
Serialized Structured Data
Where trends and changes in data elements are especially important, Flowsheet and/or Synopsis tools may be most appropriate for defining and managing data elements.
Unstructured Data
Letter or Note SmartText templates can be helpful to guide the structure and labelling of documentation content, even when there is little structured data in play.