Electronic Plan Submission Best-Practices

A Practical Guide for Jurisdictions

Avolve Software Corporation 4835 East Cactus Road, Suite 420 Scottsdale, Arizona 85254 www.avolvesoftware.com

Introduction

With the advent of electronic plan submission and review systems and their implementation by jurisdictions, the question of how to control incoming and outgoing files, and more specifically, what file formats to accept from private and commercial entities becomes an important issue for local government departments to address.

Electronic Plan Review Submission Best-Practices presents a summary of what jurisdictions should consider as they open their online doors to their respective communities and commercial partners.

The premise of electronic plan technology (ePlan) is two-fold, namely that, 1) given a choice, most professional organizations would prefer to submit plans electronically – as long as they can be assured of a secure environment and realize economic benefit, and 2) the jurisdiction is continually engaged to reduce costs, increase operational efficiency and the range and quality of services – while maintaining their regulatory enforcement mandate – by leveraging the advantages of new technology as much as possible.

In that the responsibility to develop an appropriate electronic review process and invite the community to participate in such falls to the jurisdiction, guidelines that delineate expectations and best guarantee consistent results are needed. For the citizen, knowing exactly what to do isn’t obvious, and the required details are not always easily communicated and enforced. Care must be taken to account for the plan submission aspect of ePlan system deployment and process management.

The main topics discussed in Electronic Plan Review Submission Best-Practices are as follows:

What submission formats best serve the jurisdiction for the review process (actual plan files)
Preparing the citizen-customer to submit files in the desired format according to set requirements
File security and the submission process
Post Submission Issues

Moving from paper blueprints to electronic files for plan review does provide both the citizen and the jurisdiction with several important advantages, but without proper expectations and the ability to convey them to ePlan system users, some benefits can be compromised or even evaporates.

Don’t let that be the case for your jurisdiction.

Avolve Software Corporation Makers of ProjectDox ® Electronic Plan Solutions for Government

The Plan Files: Where It All Begins

With respect to electronic plan review, the basic component that concerns everyone is the plans themselves. The majority of digital architectural and engineering plans that wind up being submitted to a jurisdiction are created using a relatively small number of engineering software products, such as Autodesk’s AutoCAD or Bentley’s Microstation. The most common native file formats produced by these programs are DWG and DGN. Native files produced by authoring software can normally be exported or saved in common portable formats such as PDF or DWF.

Drawing files that are generated in the land development and building design process are complex and often contain multiple, discipline-specific layers, imbedded data and reference information to other files created during separate design and drafting sessions by one or more designer/engineers. The native files are saved in vector-based formats that respond to manipulation by the range of design tools in the authoring program as well as third-party software applications. Because of the amount of information contained in the native file format as well as the associated data references, they are often fairly large, and present a couple of key challenges to electronic/automated processes (see Native Files below).

Converted Files vs. Native Files

Converted Files

Converting native engineering files to another format for the purpose of distribution and review is a common industry practice. The conversion operation is performed by the citizen customer prior to submission. There are essentially three options:

Bitmap Images – *Not desirable – but workable if necessary*

In some cases drawings are saved or exported as a “flattened”, single-layer representation called a bitmap image (such as Joint Photographic Experts Group [JPEG] or the Tagged Image File Format [TIFF]). TIFF files can also contain multiple pages representing different layer and design views. In some cases, this can increase the file-size for transport (sometimes dramatically), but generally prevents the drawing from unwarranted manipulation. A compression algorithm can be applied to a TIFF file (JPEGs are compressed to some degree by default) in order to reduce the size of the file for transport and/or storage.

However, when architects and/or engineers convert vector-based drawing files to bitmap images to address intellectual property security, or meet minimal jurisdictional submission requirements, important vector properties are removed including:

Layer Information – Electrical, HVAC, plumbing and other distinct elements are placed on individual drawing layers that can be revealed and hidden, allowing for faster, more accurate viewing. Without layers, reviewers will either require separate drawing files per layer, or worse, have to discern each element on the single bitmap layer – even more difficult. Being able to toggle between layers in a vector file helps all reviewers visualize the overall relationship of each layer to the others at once, even though review tasks may be restricted to a single layer in the drawing.
Font Information – Allows notes and other text-based data to be indexed and searched. Without this, finding specific information or using metadata and keywords to find it quickly is not possible. This also has an important impact on best-practices for archival and retrieval.
Scale and Measurement – Accurate measurements will force some recalibration by viewing software if measurement tools are available; if not, precise measurement can be at risk, not to mention optimum efficiency.

The above properties can be leveraged to expedite review and approval, and can support potential future operations. Thus, best-practices for plan submission will seek to avoid this type of conversion if possible, especially in the early stages of the ePlan process.

Scanned Blueprint Files – *Avoid, if possible*

Besides a paper blueprint itself, scanned blueprint files (usually TIFF), while sometimes necessary for the jurisdiction to accept and utilize, are perhaps the least desirable format for the ePlan review process, especially if the citizen-customer does the scanning. Exact alignment between multiple layers and views, visual anomalies and distortions, and overall quality control and consistency are significant issues that can compromise the original plans. If file compression is applied during export, visual information can be partially or completely discarded that might prove important for reviewers. It is recommended that, if accepting scanned documents is required for the jurisdiction, the citizen be asked to use professional scanning services prior to submission or that the jurisdiction provide them at the permit counter in order to guarantee quality scans.

Portable Vector Files – *Preferred*

Files that are converted to a portable vector format (i.e. DWF and PDF) that removes certain expendable information, but maintains important properties that assist in streamlining the review process, are preferred. Many of the jurisdictions that practice ePlan review today are standardizing on PDF as the format of choice because it is ubiquitous and supports a full complement of spatial vector data, including layers and fonts, as a “print-ready” file. Onscreen, a print-ready file is a replica of the actual paper plans that many reviewers are used to seeing. This makes transitioning to electronic review from paper easier for department staff. It should be noted that while PDF is typically accepted by jurisdictions that perform electronic plan review, conversion anomalies do exist depending on the citizen’s technical skill level and software program used for conversion – not all PDF files behave in the same way.

Native Files – *Best*

Electronic plan submission should support the use of native vector files because of all the information and attributes they contain as well as their inherent visual fidelity. However, architects and engineers are not inclined to send intellectual property-rich drawing files outside their corporate walls except under tightly structured and controlled security procedures. Also, jurisdictions are not inclined to purchase expensive CAD software seats and maintain the expertise required to use such complex tools. The apparent impasse can be solved by the proper implementation of an electronic plan system that offers:

A secure file transport, storage, access and review process and infrastructure
Automatic format conversion tools that reduce file size but maintain fidelity and the necessary attributes contained in the native DWG/DGN file format after the file has been received by the jurisdiction. Publishing technology that creates a high fidelity rendition of the original file and conveys all the necessary attributes to the screen for use by review team members, while protecting the original files from modifications guarantees the integrity of the intellectual property while delivering everything needed to optimize and automate the plan check process.
Publishing support for all common native formats used by architects, engineers and contractors.
View, markup and communication tools well-suited to the primary task of identifying and recording required changes with respect to code enforcement.

These requirements highlight the issues of file transport (moving drawing files from the author to the jurisdiction and back again) and what happens to the files during and after the initial transfer, as well as the internal review process itself. This will be discussed later in the Security section of this document.

Multiple File and Multiple Page Submission – The “Print-Ready” Master File

While it is true that (both portable and) native file formats provide the highest fidelity and the maximum amount of project information, reviewers can be disadvantaged when having to “assemble” multiple reference files if the citizen fails to consolidate them into the main, or “base” drawing file. Binding up the base file with all the external references and creating a “print-ready” master file takes a few minutes of the author’s time and saves significant time and effort for reviewers. The advantages of a print-ready file for submission will be discussed further in the next section.

Preparing the Citizen Customer for Proper Submission

Regarding electronic plan submission best practices, one of the most important tasks facing the Jurisdiction is proactively communicating with citizen customers with the goal of preparing them for file submission according to jurisdiction requirements.

Included with this white paper is a sample of such a preparation document for review. Jurisdictions are encouraged to learn and borrow good ideas from their peers at other communities. Keep in mind that, for the citizen, it is likely that little or no preparation for submission occurs prior to the permit application, which means that there is a window of opportunity to communicate what is expected. However, unless detailed submission requirements are communicated clearly in a timely fashion, the user experience, for citizens and reviewers, will be problematic.

Preparing the citizen customer includes the following activities:

Developing an effective and thorough submission process
Establishing detailed submission requirements
Creating an effective requirements delivery vehicle to the customer
Implementing methods to confirm that communication has taken place
Setting up some accountability within the process

Developing an Effective Process

It goes without saying that some form of submission process must occur with any ePlan system deployment. The question is how much time and effort will be spent to ensure that the process is well-conceived and accounts for all the contingencies involved. Implementing an ePlan solution is, for most every jurisdiction, uncharted territory and involves some trial and error.

Often jurisdictions will, at first, choose to develop their ePlan solution under a shroud, not wanting to risk too much public or inter-departmental exposure while ironing out the wrinkles and fixing the bugs. However, the most successful programs engage a sample of the internal stakeholders and citizen (usually commercial) customers early-on, first to help promote the advantages of new technology, but also to solicit valuable input in pursuit of a system and processes that actually meet users’ needs. It is recommended that, at appropriate milestones in the project implementation plan, that real-world users become exposed to system features with a view to refining it for broad use in the community. Preparing the customer means understanding how he/she performs his/her job and steering them in the required direction, and not always dictating a set of rules. Jurisdictions have yet to report a refusal to participate on the part of their prominent stakeholders.

Establishing Submission Requirements

The previous section dealt with file formats and their characteristics. Proper submission also includes the consistent labeling of files and sheets, including a complete index of all files being submitted. While every jurisdiction will have differing requirements based on previous practices, it is important to consider the differences between digital media and paper when developing requirements for submission, and also the complete lifecycle of the files submitted. Will

Figure 1: Sample Electronic Plan Submission and Review Workflow

(Courtesy of Osceola County Building and Planning)

See Attached Image

the files be named one way for review and another way for archiving? Which files will be kept? How many revisions of a given file or sheet? The entire process should be accounted for before issuing requirements for the citizen-customer in order to avoid unnecessary modifications.

A checklist that becomes part of the standard procedure for citizens can include:

Submission cover sheet
Project cover sheet and file index
Drawing file naming conventions – some jurisdictions utilize portions of the permit application number
Sheet naming conventions – establish a sheet naming convention that conforms to your operational and lifecycle plan. (see Figure 2a, next page)
Border standards – establish designated areas for stamps and title blocks, etc.
File-type standards – list acceptable file types for each type of document, drawing, image etc. You can also provide instructions regarding how the customer should convert or publish specified documents.
Folder Structure standards – discuss which folders various document and drawing files should be uploaded to when submitting/re-submitting.
Markup/Annotation color conventions – establish which colors will relate to specific disciplines (see Figure 2b, next page)

Single File/Single Drawing/Single Sheet (See Multiple File and Multiple Page Submission above)

While there are many potential ways to package up drawings for submission, it is advisable to instruct the citizen customer to provide drawings as single files containing a single sheet, and not as multi-page files. The idea is to prepare the submission in such a way that when a file is opened onscreen a single sheet is displayed – just like rolling out a single blueprint sheet. Had they chosen to submit in paper, citizen customers would prepare their files for the reprographics house in the same fashion, so it is not extraordinary to require this type of packaging. The term “print-ready” mentioned above appropriately describes the status of files ready for ePlan submission.

There are several advantages to this method. Individual drawing files containing multiple pages and multiple layers are unnecessarily complicated to navigate and manage. When corrections and markups are necessary (and they are always necessary) extracting single pages from multi-page files can be time consuming at best, and confusing or the cause of file corruption at worst. A single sheet with a unique filename for markups and annotations is much more direct and easy for both reviewers and citizens to identify, modify and then re-submit. If a single sheet file becomes corrupt, remaining sheet files can still be used; a corrupt multi-page file is of no use. Collections of sheets can be divided up into separate folders for department-specific reviews when required. Maintaining a single-file to single-drawing sheet relationship also makes it possible to leverage side-by-side and overlay-compare features easily and accurately.

Single sheets can contain multiple layers, and if converted to a portable format such as PDF, combined into a single file at the conclusion of the project for archiving if that is deemed necessary. Layers on single sheet files can be turned on and off in order to isolate views and add comments and markups normally.

Delivering Requirements to Citizen Customers

Making sure that a customer receives and reviews your requirements, as well as being able to comply with them with reasonable effort, is also essential. It is a good idea to map various delivery and verification steps into the overall submission process. Jurisdictions can provide this in the following ways:

Develop a electronic plan submission guide that incorporates a requirements checklist and submission steps in a single, easy-to-use document that is accessible in print and online. (see the sample provided – courtesy of Clark County, Nevada Planning and Development)
Use the existing permit application process as an opportunity to educate the citizen customer. If online permit application is available, use the web-based process (web pages) to promote ePlan submission. Use the permit counter/manual application process in the same way - people waiting in line can use their time to become aware of and learn about electronic plan submission. Make sure that you provide multiple paths to the information. One jurisdiction actually allows citizens to “test drive” electronic plan submission so they can see how easy it is.
In online permit application scenarios and email communication, optimize the use email notification combined with web technology to educate and even verify required activity. Examples include auto-generated emails with embedded instructions and/or attachments (such as the submission guide), e-form web pages that record activity and update status, and time or event-triggered notifications. Workflow technology can be utilized to automate communication, such as sending reminders to keep the process moving. Polling plan directory folders per a schedule can provide the jurisdiction with information about citizen activity, such as when submissions have occurred and what folders have been populated.

Drawing Type	Discipline	Sheet Number	Example File Names
Architectural	A	000-999	A010
Interior Design	ID	000-999	ID009
Structural – All Structural and related plans, including details	S	000-999	S002
Plumbing	P	000-999	P1.99
Electrical	E	000-999
Smoke Control	SC	000-999
Mechanical	M	000-999
Landscape	L	000-999
Civil	C	000-999
Life Safety Package and Master Egress	LSP	000-999
Alternate Method	AM	000-999

Figure 2a: Drawing Sheet Naming Table

Markup Name	Changemark Title	Markup Color
Architectural	ARCH	Purple
Civil	CIVIL	Blue
Electrical	ELEC	Yellow
Fire Protection	FP	Burgundy
Geotechnical	GEO	Green
Plumbing	PLUM	Orange
Mechanical	MECH	Orange
Smoke Control Diagrams	SMOKE	Burgundy
Steel Fireproofing	SFP	Burgundy
Structural	STRU	Brown
Zoning	ZONING	Red

Figure 2b: Markup/Changemark Color Legend

A word of caution: Leveraging technology opens up a number of ways to help automate tasks, but applying technology to a flawed process will not fix it. Be sure to assess the fundamental aspects of what you are trying to accomplish with respect to your citizen-customer and then use technology to enhance them.

Accountability Support

When all is said and done, the jurisdiction will need to apply human activity to check that the requirements for submission have been met. Current ePlan technology still requires oversight and assistance from the review team. However, if citizen-customers have the opportunity to be exposed to the proposed process prior to implementation and provide feedback, it is very possible for the jurisdiction to deploy a well-conceived submission methodology that communicates requirements effectively and minimizes the need for excessive monitoring.

Security and the Submission Process

Another important issue that jurisdictions must address when implementing electronic plan submission best-practices is providing a secure and managed way to upload files to a central file server. Regarding security, uploading files via a network is not really the problem; the issues lie with the proper controls needed to send/receive files from multiple and disparate sources and then automatically join them to a permit processing and accounting system that is run separately of the plan review process.

However, using the Web presents its own set of challenges, which are as follows:

Network Security – Any publicly-accessible network system being used to transport plan files must be reasonably secure to the extent that network pipes and file servers cannot be infiltrated or disrupted by unauthorized and hostile personnel. Best-practices for implementing such a network/server system are established and continue to evolve, so they are not the subject of this plan submission discussion.

Trusted Sources – Network and file security raises the subject of trusted sources. With respect to network protocols, the standard HTTPS Web protocol utilizing SSL is the only practical choice for a publicly accessible network and accompanying file transfers, because it is ubiquitous and incorporates a means of verifying the identities of the nodes uploading files to the jurisdiction as well as providing trust that the jurisdiction is the actual destination of the files being sent. Some jurisdictions are planning to require pre-qualification, training and managed accounts for commercial firms that will be uploading multiple files often. Trusted source issues also touch on the practice of “wet-sealing” plans, proper sign-offs and current state regulations that sometimes require affixed seals prior to submission.

Wet-Seals and Digital Signatures –A concern that dovetails with the topic of trusted sources is the practice of wet-sealing architectural and engineering plans. Electronic plan submission assumes that no paper documents have been required of or generated by the citizen-customer during the submission process, or by the jurisdiction through the end of the review. However, many states and standards bodies require “wet-seals” or other types of affixed seals to paper documents submitted to the jurisdiction prior to plan review and approval. Regrettably, with respect to an all-digital process, there is no prospect of meeting every state’s requirements in one fell swoop even if an industry-standard digital signature methodology existed – and it does not.

Jurisdictions are trying different ways to meet wet-seal requirements half-way in an effort to accommodate the law. Some require a single, full set of wet-sealed plans up front – once. Others are asking that the citizen-customer provide a wet-sealed index list of all plan sheets which they can verify after the drawing sheet files are uploaded. Some have considered asking the architect/engineer to wet-seal the final set of approved plans that are printed and ship a set back to the jurisdiction.

The means to perform a legitimate digital signature is well established; it is the application of the technology in the context of the submission/re-submission process that poses the challenge, especially as it concerns widespread required use, technology costs, ease-of-use, and liability as the law defines it.

There is one common thought that prevails among all the jurisdictions deciding for electronic submission and review: Despite current laws, the wet-sealing issue is not going to stop them from implementing electronic plan technology – in at least some fashion – because the advantages of doing so are too numerous. There are efforts underway to tackle the question of a fully digital, certifiable signature/seal process that does away with the need for the traditional wet-seal, but if jurisdictions wait for state legislatures to act, they will fall too far behind technologically.

A best-practice for this aspect of electronic plan submission currently does not exist. Jurisdictions are encouraged to 1) design a system and process that is legally viable and sensible, and 2) contact their electronic plan review peers and continue exploring what is being done to deal with this particular issue.

Submission Lock-Down – Jurisdictions need to control access to project folders based on the specific phase of the review process. A key security practice is to provide a means to determine when all required files have been received and then shut off access to the file folders from any outside person or entity. Failure to do this allows for the potential modification of critical files in mid-review. Re-submission should occur only according to the designated completion of specific tasks by each department.

Electronic Approval/Rejection Stamps – For the foreseeable future, moving to paper is still the practical way for a construction entity to utilize the plans on the job site, and so jurisdictions employing electronic plan submission and review will need to decide how best to accommodate this step. Electronic plan technology allows the Plan Review Supervisor to “stamp” the plans with a tamper-proof electronic image that is “burned into” the approved plan set and is checked by the Field Inspector when he reviews the permit and the construction drawings on the jobsite.

Bandwidth – Sufficient network bandwidth must be in place to expedite the transfer of multiple and potentially large files without interruption, creating a consistent and pleasant user-experience. File compression is often used to reduce the overall size of the file transfer and minimize bandwidth use.

NOTE: ProjectDox®, the electronic plan solution from Avolve Software Corporation, creates screen renditions of all submitted files, no matter the native or converted format. All “original” files submitted are stored and cannot be accessed except by specific permission. Markups and annotations are applied to virtual layers that are managed by the ProjectDox application. It is not possible to modify any design element of a drawing sheet file with the tools given to ProjectDox users – such is reserved solely for the author of the native file. Combined with a proper workflow process and applied user permissions, it is virtually impossible to effect any change to a drawing file when using ProjectDox. This is an important security feature for system users concerned with the file integrity through an electronic submission and review process via LAN/WAN technology.

Post-Submission

Using electronic plan technology workflow tools and other features, jurisdictions can effectively address post-submission concerns surrounding re-submission, approval and printing, inspection, as-built drawings and archiving.

A few comments regarding some of these issues:

Re-submission should be done as “print ready” files – discussed above
Use file compare features extensively to review re-submitted plans in order to catch modifications that were not present in the initial submission and therefore not subject to review.
Approved plan sets should be stamped electronically and “burned in.” Final, approved plans should be easily identifiable and stored in a specific folder. PDF is a preferred format for download by the citizen-customer.
If required, approved plan sets can be printed and wet-sealed by the Architect/Engineer as a binding legal document in possession by the jurisdiction.
Inspectors should be made aware of the ePlan process and verify all applied jurisdictional certifications on the job-site plan set. They should be granted access to final, approved plan sets online to make notations and corrections per the jurisdiction’s “As-Built” process.
Discrepancies between the job site and approved plans are to be noted and corrections made through additional, post-inspection notification and resubmission by the citizen-customer. Certificates of Occupancy can be dependent upon receipt of accurate As Built plans in the system.
Archiving project files should be done in such as way as to facilitate easy, rapid retrieval and distribution to authorized agencies and personnel when structures and/or land areas are deemed critical to community safety and security. Many different criteria can be applied against a particular project to determine its specific and overall importance. It is recommended that post-project accessibility be included in any ePlan deployment planning exercise.

To get more information or speak to an ePlan expert, contact:

Avolve Software Corporation

4835 East Cactus Road, Suite 420

Scottsdale, AZ 85282

602.714.9774

www.avolvesoftware.com

info@avolvesoftware.com

Revised 02-18-2015

Electronic Plan Submission Best-Practices

A Practical Guide for Jurisdictions

Related articles