RFI/RFP Template (Updated)

Editor's Note: This update replaces the June 2007 RFI/RFP practice brief te plate! The request for information/request for proposal (RFI/RFP) process is vital to procuring a system that meets organizational and user needs. ecause of this! it is imperative that adequate time "e allotted for the process. This template is provided as a sample tool to assist healthcare providers as they issue an RFI or an RFP for electronic health record (#$R) or component systems. It is meant to "e used in con%unction &ith the practice "rief titled 'The RFP Process for #$R (ystems.' $ealthcare providers should customize this sample template "y using the components that are applica"le for their needs! adding components as necessary! and deleting those that are not. (ections ) and * should "e completed "y the facility.
).

Introduction (introducing the facility to the vendor) a. rief +escription of the Facility

(,hildren-s is the largest non.governmental provider of pediatric care in the +istrict of ,olum"ia! providing more than /01 million in uncompensated care. It serves as the regional referral center for pediatric emergency! trauma! cancer! cardiac and critical care as &ell as neonatology! orthopedic surgery! neurology! and neurosurgery. 2dditionally! ,hildren-s 3ational 4edical ,enter is home to the ,hildren-s Research Institute! the (hei5h 6ayed Institute for Pediatric (urgical Innovation! as &ell as the ,hildren-s 3ational $eart Institute! the 7il"ert Family 3eurofi"romatosis Institute! the rain Tumor Institute! and the 8"esity Institute. ,hildren and families travel locally! nationally! and internationally to see5 the e9pertise of our pediatric specialists and nationally recognized nursing staff).
".

Facility Information i. ,omplete 2ddress

)". ii. ,hildren-s 3ational 4edical $ospital ,enter is a e9clusive provider of pediatric care in the 4etropolitan :ashington 2rea. ,hildren-s 3ational 4edical $ospital ,enter is also a proven leader in the development and application of innovative and ne& treatments for childhood illness and in%ury. iii. #very year the 2cademic Pediatric 2ssociation (2P2) selects one national a&ard &inner in the health care delivery category to recognize innovation ! effectiveness and care e9cellence in a delivery system that includes medical students and residents. The ,hildren-s 3ational 4edical ,enter is the recipient of the 2cademic Pediatric 2ssociation (2P2) $ealth ,are +elivery 2&ard for the year *11; . Locations in the Metro area include: ). 4ain $ospital! ))) 4ichigan 2ve. 3.:. :ashington +, ! *11)1! Phone< *1* .=>?.0110

*. ,hildren-s Pediatricians and 2ssociates +rs. $udson @ (imrel *?11 3aylor R+.! (.#! :ashington +, *11*1 A. ,hildren-s Pediatricians and 2ssociates ! +rs. ,hang.Pitter ! $am"urger ! Baplan ! Ratner ! (choonover !(epe ! (mith.Bhuri and :agner. *)=) B (t. 3.:. (uite =1) :ashington +, *11A> Phone nu. *1*.CAA.=0=A . =. ,hildren-s Pediatricians and 2ssociates ! )A;11 Daurel Da5es 2ve. (uite *=1 Daurel 4d. *1>1>. 0. ,hildren-s 8utpatient ,enter of 3orthern Eirginia ! C01) 2rlington oulevard (uite *11 Fairfa9 E2. **1A) Phone nu. 0>).**?.CAC1 ,enter 4gr. . (teve (aunders. This is %ust to name a fe&.
ii.

iii.

Enterprise Information The organizations should provide all relevant information including &hether the facility is a part of a healthcare delivery system! the facilities that are included in the pro%ect! and their locations. Si e The organization should provide any information that &ill "e relevant to the product such as the num"er of discharges! visits! "eds! etc. The components of ,hildren-s $ospital include the follo&ing< F A1A "eds of &hich 0= are level III, 3e&"orn Intensive ,are Gnit "assinetsH a ,ardiac Intensive ,are GnitH a 3euro Intensive ,are GnitH a Devel I pediatric trauma center &hich serves A statesH and a critical care transport team. F #ight Regional 8utpatient ,enters F ,hildren-s 3ational $ealth 3et&or5 &ith more than >01 affiliated pediatricians !are at !hildren"s #ospital include the follo$in%: F F F F F Eisits to off.campus 8utpatient ,enters C0!*0; Eisits to on.campus 8utpatient ,linics ))1!);> Eisits to ,hildren-s $ealth ,enters C1!A;) #mergency +epartment visits >0!A*0 #valuation and Treatment Gnit =!>1; I Total 8utpatient visits A00!CC) )!1*)!;)) )11!;=A 0.; days

F Da"oratory tests performed F +iagnosis imaging performed F 2verage length of stay

iv.

7eneral +escription of ,urrent (ystems #nvironment The organization should provide general information regarding current information systems structure (i.e.! hard&are and operating systems).

c.

(cope The organization should provide a "rief narrative description of the pro%ect that

the RFP covers and the environment sought (e.g. phased approach! hy"rid support). *. (tatement of Purpose a. 8verall usiness 8"%ectives/+rivers The organization should list high.level "usiness goals it is loo5ing to achieve "y implementing the soft&are. ". Bey +esired Functionality :hen requesting information for the facility.&ide solution (e.g.! #$R)! the organization should list the various features and functions of the system desired! as &ell as any pertinent details. i. ,linical Repository ii. ,linical +ocumentation iii. ,omputerized Physician 8rder #ntry (,P8#) iv. 2ncillary (upport (e.g.! la"oratory! radiology! pharmacy! etc.) v. Picture 2rchiving ,ommunication (ystem (P2,() vi. #lectronic +ocument 4anagement/+ocument Imaging vii. ,ustomiza"le :or5flo& 4anagement viii. Interopera"lity (e.g. for health information e9change) i9. Patient Portals 9. 8ther ". $I4 +epartment 8perations :hen requesting information for the $I4 solution! the organization should list the various processes and functions of the system it is loo5ing for! as &ell as any pertinent details. i. ,hart 2nalysis/+eficiency 4anagement ii. ,oding/2"stracting iii. Patient Identity 4anagement/#lectronic 4aster Patient Inde9 (e.4PI) iv. $ealth Record 8utput and +isclosure 4anagement v. Release of Information vi. (creen Input +esign vii. (upport for 4andated Reporta"le +ata (ets viii. 8ther &'( (ystem 2dministration .. Records 4anagement and #videntiary (upport This functionality is applica"le to or used for all components or modules of an application. Facility requirements for this functionality should "e specified in the detailed system requirements. Use )dministration Gser 2dministration consist of Inpatient Physicians ! Residents ! 3urse Practitioners ! Physician 2ssistants and 4edical (tudents. ". Gser I+ and Pass&ord is required to access the system. )ccess Pri*ile%e !ontrol Mana%ement
a.

(ome of the 2ccess Privileges for control management are as follo&s <

J J J J J J J J J J

2llo&s vie&ing and composing in"o9 messages Kou can create telephone encounters $elps to "etter understand patient dash"oard 3avigating through office visit screen ! including patient status +ocumenting in progress notes ! including "illing information ,reating defaults 2ccessing letters ,orrecting chart errors &ith a "lan5 note ,ompleting the patient discharge and transfer process Gnderstanding &hat to do during a computer do&n time

Lo%%in% Functions ). To log on you must enter a user name and pass&ord *. Press the log.in "utton A. 2 dialog "o9 &ill appear as5ing if you &ould li5e the system to remem"er your user name and pass&ord for future log.ins. If you select yes ! you &ill not "e required to enter this information on future log.ins

)uditin% Function The audit process chec5s your data and flags areas &here pro"lems are found. The process is as follo&s < i. ii. ,lic5 audit If your credentialing application is error free ! you &ill receive the data audit valid screen. ,lic5 ne9t ! to proceed. If errors are encountered the data audit screen &ill display &ith a list of the errors ! details and lin5s to the pages containing the errors. ,lic5 the hyperlin5 of the first required fi9es error. The page on &ith the error &ill display. ,orrect the required fi9es error(s) on the page or enter missing information. #rrors &ill "e flagged &ith a red L(asteris5) ,lic5 the red L to receive information regarding the error. ,lic5 8B at the "ottom of the page to update and return to the audit ta". :hen the last error has "een corrected the data audit valid screen &ill appear. ,hoose ne9t to proceed to authorized screen.

iii. iv. v. vi.

+i%ital Si%nature Function

). +igital (ignature Function ensures that the electronic document (email ! spreadsheet ! te9t ! file etc. ) is authentic. ". 2uthentic means that you 5no& &ho created the document and that it has not "een altered in any&ay since that hospital or clinic created it. c. +igital (ignature is needed in the hospital for Patient consent ! 2uthority of medications ! +ata 2uthenticity ! Patient and Practitioner satisfaction and more. d. 4any signature acts are mandated "y the state and federal $ealth care regulation. Records Mana%ement Function ). 2llo&s the practicing physician to immediately access patient records electronically for improved care monitoring management. *. Improves communication &ith specialty providers and securely e9changes essential health care data &ith other ma%or providers. A. :ith a #4R(#lectronic 4edical Record) the documentation process allo&s the provider to achieve document legi"ility ! scan out redundancy ! completeness and compliance in a rapid time frame. =. :ith this function patient histories do not have to "e gathered over and over and patient visit is streamlined. 0. Physician practices are a"le to have "etter ,oordination and ,ontinuity of patient care. ?. Physicians are a"le to provide "etter quality care and have "etter outcomes for the children around the region.

2ccess Privilege ,ontrol 4anagement Dogging/2uditing Function +igital (ignature Functions Records 4anagement Function 2rchiving Functions ,ontinuity of 8perations (e.g. support for "ac5up! recovery) 4aintenance of (tandardized Eoca"ularies and ,ode (ets ($#R## :IDD # +8I37 2+4I3I(TR2TI83 23+ FGTGR# PD23(. c. Future Plans 7eneral description of long.term plans! including identified future systems environment and pro%ected timeta"les.
i. ii. iii. iv. v. vi. vii. viii.

(ections A and = should "e completed "y the vendor! Requirements Eendors should provide availa"ility and timelines for development of soft&are to fulfill requirements not availa"le at this time. a. Gser Requirements #ach functional area is e9pected to have its o&n set of user requirements.
).

(ample questions related to $I4 functional user requirements and features are provided "elo&. This ta'le is a sample only. ,r%ani ations must customi e this RFP template to meet their needs(

Functional User Re-uirements/Features. )*aila'l e !hart !ompletion/+eficienc0 )nal0sis ,an the organization define the intervals for aging analysis (e.g.! >.days! )=.days! *). days! etc.)M +oes the system allo& for standard and ad. hoc reporting for chart deficiency/delinquency analysisM ,an delinquency reports "e sent to physicians/clinicians in electronic (e.g.! e. mail or fa9) and paper formats (letters)M +oes the system allo& you to define or detail all deficiencies "y provider! "y area of deficiency! or other com"inations (e.g.! group practices! etc.)M +oes the system allo& the organization to list all records (charts) "y the deficiency typeM ,an deficiency analysis "e conducted at the time the patient is prepared for discharge from the facilityM +oes the system support most industry standard dictation systems to allo& transcri"ed reports to "e easily and efficiently completedM +oes the system allo& for end.user notification &hen information identified as incomplete/missing is completedM !odin% !ompletion/)nal0sis +oes the system support automation of coding &or5 flo& (e.g. computer.assisted coding)M +oes the system support automated case assignment to &or5 queuesM ,an the user assign cases "ased on special attri"utes (e.g. EIP! dollars! or case type such as cancer or trauma! etc.)M +oes the system support online communication "et&een employees and

!ustom +e*elope d

Future +e*elopmen t

/ot )*aila'le

managersM +oes the system support most industry standard encoders/groupersM +oes the system support "oth on.site and remote coding activitiesM +oes the system support assignment of high. ris5 coding to supervisory staff or allo& coding verification as staff complete casesM +oes the system contain tools for monitoring and evaluating the coding processM +oes the system support electronic query capa"ilitiesM !odin%/Transaction Standards (see also Section 1(2) +oes the system support I,+.)1.,4 and/or I,+.)1.P,( in addition to I,+.;.,4M +oes the system use 7eneral #quivalence 4appings (7#4s)! such as "et&een I,+.)1. ,4/P,( and I,+.;.,4 or (384#+ ,T and I,+.;.,4M Is the system compliant &ith the Eersion 01)1 transaction standardM #ealth Record ,utput and +isclosure +oes the system allo& a unified vie& of all component su"systems of the #$R at the individual patient level and at the date of service encounter level for purposes of disclosure management (including the a"ility to print and generate electronic output)M +oes the system provide the a"ility to define the records or reports that are considered the formal health record for a specified disclosure or disclosure purposesM +oes the system allo& EIP patients to "e flagged and listed confidentially on corresponding reports (i.e.! census)M +oes the system produce an accounting of disclosure! reporting at a minimum the date and time a disclosure too5 place! &hat &as disclosed! to &hom! "y &hom! and the

reason for disclosureM +oes the system provide the a"ility to create hard copy and electronic output of report summary information and to generate reports in "oth chronological and specified record elements orderM +oes the system provide the a"ility to include patient identifying information on each page of electronically generated reports and provide the a"ility to customize reports to match mandated formatsM +oes the system allo& for redaction and recording the reason! in addition to the a"ility to redact patient information from larger reportsM Release of Information (3ote< 2dministrative
release of information functionality may or may not "e an integral component of an #$R system.)

+oes the system support $IP22 management of non.TP8 disclosuresM +oes the system trac5 and report the date/time release of information requests are received and fulfilledM +oes the system allo& the a"ility to trac5 &hether the release of information consent/authorization &as adequate! in addition to a corresponding dispositionM +oes the system generate invoices &ith user. defined pay scalesM +oes the system allo& trac5ing of payments receivedM +oes the system generate template letters for standard correspondence (e.g. patient not found! date of service not valid! etc.)M +oes the system allo& information to "e released electronicallyM )uthentication +oes the system authenticate principals (i.e.! users! entities! applications! devices! etc.) "efore accessing the system and prevent access to all nonauthenticated principalsM

+oes the system require authentication mechanisms and can the system securely store authentication data/informationM If user names and pass&ords are used! does the system require pass&ord strength rules that allo& for a minimum num"er of characters and inclusion of alphanumeric comple9ity! &hile preventing the reuse of previous pass&ords! &ithout "eing transported or vie&a"le in plain te9tM +oes the system have the a"ility to terminate or loc5 a session after a period of inactivity or after a series of invalid log.in attemptsM )ccess !ontrols +oes the system provide the a"ility to create and update sets of access.control permissions granted to principals (i.e.! users! entities! applications! devices! etc.) "ased on the userNs role and scope of practiceM +oes the system inactivate a user and remove the userNs privileges &ithout deleting the userNs historyM +oes the system have the a"ility to record and report all authorization actionsM +oes the system allo& only authorized users access to confidential informationM +oes the system prevent users &ith read and/or &rite privileges from printing or copying/&riting to other mediaM +oes the system define and enforce system and data access rules for all #$R system resources (at component! application! or user level! either local or remote)M +oes the system restrict access to patient information "ased on location (e.g.! nursing unit! clinic! etc.)M +oes the system trac5 restrictionsM +oes the system have the a"ility to trac5/audit vie&ed records &ithout significant effect on system speedM +oes the system allo& for electronic access

to specified patients/encounters for e9ternal revie&ersM Emer%enc0 )ccess !ontrols +oes the system allo& emergency access regardless of controls or esta"lished user levels! &ithin a set time parameterM +oes the system define the accepta"le circumstances in &hich the user can override the controls for emergency access! as &ell as require the user to specify the circumstanceM +oes the system require a second level of validation "efore granting a user emergency accessM ,an a report "e generated of all emergency access useM +oes the system provide the a"ility to periodically revie&/rene& a userNs emergency access privilegesM +oes the system provide the a"ility to generate an after.action report to trigger follo&.up of emergency access useM Information )ttestation +oes the system provide the a"ility for attestation (verification) of #$R content "y properly authenticated and authorized users different from the author (e.g.! countersignature) as allo&ed "y usersN scope of practice! organizational policy! or %urisdictional la&M If more than one author contri"uted to the #$R content! does the system provide the a"ility to associate and maintain all authors/contri"utors &ith their contentM If the #$R content &as attested to "y someone other than the author! does the system maintain all authors and contri"utorsM +oes the system provide the a"ility to present (e.g.! vie&! report! display! access) the credentials and the name of the author(s) and the attester! as &ell as the date and time of attestationM

+ata Retention3 )*aila'ilit03 and +estruction +oes the system provide the a"ility to store and retrieve health record data and clinical documents for the legally prescri"ed time or according to organizational policy and to include unaltered in"ound dataM +oes the system provide the a"ility to identify specific #$R data for destruction and allo& for the revie& and confirmation of selected items "efore destruction occursM +oes the system provide the a"ility to destroy #$R data/records so that data are not retrieva"le in a reasona"ly accessi"le and usa"le format according to policy and legal retentions periods! and is a certificate of destruction generatedM Record Preser*ation +oes the system provide the a"ility to identify records that must "e preserved "eyond normal retention practices and identify a reason for preserving the recordM +oes the system provide the a"ility to generate a legal hold notice identifying &hom to contact for questions &hen a user attempts to alter a record on legal hold or an unauthorized user attempts to access a record on legal holdM +oes the system provide the a"ility to secure data/records from unaudita"le alteration or unauthorized use for preservation purposes! such as a legal holdM +oes the system provide the a"ility to merge and unmerge recordsM +oes the system allo& a record to "e loc5ed after a specified time so no more changes may "e madeM Minimum Metadata Set and )udit !apa'ilit0 for Record )ctions +oes the system capture and retain the date! time stamp! and user for every o"%ect/data creation! modification! vie&! deletion! or

printing/e9port of any part of the medical recordM +oes the system retain a record of the vie&erM +oes the system retain a record of the author of a changeM +oes the system retain a record of the change historyM +oes the system retain a record of the source of nonoriginated dataM +oes the system retain the medical record metadata for the legally prescri"ed time frame in accordance &ith the organizational policyM +oes the system include the minimum metadata set for a record e9changed or releasedM Pendin% State +oes the system apply a date and time.stamp each time a note is updated (opened/signature event)M +oes the system display and notify the author of pending notesM +oes the system allo& the a"ility to esta"lish a time frame for pending documents "efore administrative closingM +oes the system display pending notes in a &ay that clearly identifies them as pendingM +oes the system allo& the author to complete! edit! or delete (if never vie&ed for patient care) the pending noteM )mendments and !orrections +oes the system allo& the author to correct! amend! or augment a note or entryM +oes the system allo& the author to indicate &hether the change &as a correction! amendment! or augmentationM +oes the system record and display the date and time stamp of the changeM

+oes the system provide a clear indicator of a changed recordM +oes the system provide a lin5 or clear direction to the original entry/noteM +oes the system retain all versionsM +oes the system disseminate updated information to providers that &ere initially autofa9edM +ocumentation Succession Mana%ement and 4ersion !ontrol +oes the system manage the succession of documentsM +oes the system retain all versions &hen a change is madeM +oes the system provide an indicator that there are prior versions (&hen appropriate)M +oes the system indicate the most recent versionM Retracted State +oes the system allo& for removing a record or note from vie&M +oes the system allo& for access of a retracted note or recordM +oes the system allo& the user to record the reason for retractionM +oes the system allo& for notification of the vie&ers of the data to present correct information (if applica"le)M +ata !ollection and Reportin% +oes the system allo& for real.time data collection and progress measurement against preset targetsM +oes the system produce reports on turnaround days! dollars pending! costs per chart "y process! days to "illing! and so on! as related to 2RM +oes the system have the a"ility to trac5 clinical decision.ma5ing alerts (e.g.! &hen they &ere added to the system or

discontinued! used! ignored! etc.)M +oes the system comply &ith meaningful use reporting requirementsM Patient Financial Support Is your proposed solution fully integrated (or a"le to interface &ith the patient financial system)! offering users an electronic form of the "usiness officeM ,an patient information "e placed in folders to easily identify those details that refer to the patient (guarantor) account(s)M ,an you electronically capture! store! and retrieve computer.generated documents and reports! such as the G .1= or the ,4( )011! &hich are $IP22 transaction standard compliantM Patient Portals +oes the system allo& for electronic patient access (e.g.! :e" portal)M #ealth Information E5chan%e +oes the system ena"le participation in local health information e9change initiativesM a. (ystem Requirements 8rganizations should provide a list to vendors of &hat current technology needs to "e supported. Eendors should then provide information on their system-s availa"le requirements. (ample questions related to system requirements and features are provided "elo&. This ta'le is a sample only( ,r%ani ations must customi e this RFP template to meet their needs( S0stem Re-uirements/Features. 6eneral S0stem Re-uirements Is the system integrated or interfacedM +oes the system provide the a"ility to archive via tape! ,+! or +E+M +escri"e any other options. 2re the ,8D+ (computer output to laser disc) data streams availa"le in 2(,II (2merican (tandard ,ode for Information Interchange)M +oes the system support audit trails at the folder level for managing access! editing! and printing of documentsM )*aila'l e !ustom +e*eloped Future +e*elopment

/ot )*aila'

+oes the system ma5e audit trail logs availa"le to the organization! including the date! time! user! and locationM +oes the system support an online help function/featureM Is the proposed solution scala"le (e.g.! can it support 01 to C11 &or5stations! concurrent users! etc.)M +oes the system have the capa"ility of recording change management logs related to platform upgrades and patchesM ,an the system identify or distinguish the facility location in a multi.entity environmentM ,an the system support a centralized data"ase across multiple facilitiesM $o& compliant is your product &ith the $D>-s #$R.( F4 and #$R profilesM (Please provide us &ith your $D> #$R. ( F4 and profile conformance statements.) S0stem Securit0 +oes the system monitor security attempts for those &ithout user rights and those logged in the audit trail/logM +oes the system trac5 all activity/functions! including &here they change the data"ase! and can they "e managed through the audit trail/logM +oes the system use encryption methods that render protected health information unreada"le in compliance &ith the latest industry approaches and guidelinesM Technical Re-uirements +o communication components include T,P/IP (transmission control protocol/internet protocol)M +oes the system use ,,ITT 7roup III! IE for compression schemesM +oes the system support standard $D> record formatting for all input and outputM +oes the system support (OD for communicationM +oes the system support thin client P,sM Is the system sized for capacity to allo& for planningM +escri"e your recommendations. +oes the system support dis5 shado&ing and system redundancy provisionsM Please descri"e. ,an your solution "e supported as an 2pplication (ervice Provider (2(P) hosted modelM

+oes the system support "ro&ser."ased optionsM Inte%ration of /arrati*e /otes +oes the system support $D>Ns ,linical +ocument 2rchitecture Release * (,+2.R*) standard for the encoding of narrative! te9t."ased clinical informationM +oes the system receive! display! transform! and parse ,+2.encoded clinical documents as descri"ed in the $D> ,+2.R* Implementation 7uides for document types! such as $istory and Physical 3ote! ,onsultation 3ote! 8perative 3ote! and +iagnostic Imaging ReportM +oes the system receive! display! transform! and parse ,+2.R*.compliant documents &ith encoded headers (Devel ) encoding)M +oes the system process ,+2.R*.compliant documents that include Devel * encodingM +oes the system process ,+2.R*.compliant documents that include Devel A encodingM

Interfaces 8rganizations should provide a list of e9isting interfaces that &ill need to "e supported! as &ell as ne& interfaces that &ill have to "e created and supported! including any pertinent interopera"ility information that e9ists and &ill "e needed in the future. Eendors should provide information regarding their system-s a"ility to meet the organization-s interface requirements. ). Eendor Ouestionnaire The organization should request information a"out the vendor and the product to assist &ith decision ma5ing. a. Eendor ac5ground and Financial Information i. ,ompany 3ame and 7eography The organization should request an address of a "ranch close to the facility! as &ell as the headquarters. (taff may &ant to visit "oth. ii. ,ompany 7oals iii. Kear the ,ompany :as #sta"lished! (ignificant ,ompany 4erges! 2cquisitions! and (ell.offs iv. :hether the Eendor Is Pu"lic or Privately 8&ned v. an5ruptcy/Degal Issues (including under &hich name the "an5ruptcy &as filed and &hen! or any pertinent la&suits! closed or pending! filed against the company.) vi. Research and +evelopment Investment (e9pressed in a total amount or percentage of total sales) vii. (tatus of ,ertification
a.

".

c.

".

".

".

c.

". c.

d.

e.

(tatement of Bey +ifferentiators The vendor should provide a statement descri"ing &hat differentiates its products and services from those of its competitors. ,ustomer ase and References i. ,ustomer Dist (or total num"er of customers per feature or function! if a list of customers cannot "e provided o&ing to confidentiality/privacy concerns) ii. References that ,an e ,ontacted The vendor should provide references the facility can contact/visit "ased on product features and functions most suita"le to the facility! as &ell as those using the latest versions of the soft&are. Oualifications i. The vendor should provide a list of qualifications and resume! including a sample list of similar pro%ects and clients. Gser Participation i. Gser 7roups 8rganizations should provide a list of the user groups and as5 &hether it can attend a meeting or a call for revie& purposes. ii. Requirements 7athering The vendor should request information regarding customer participation in requirements.gathering stages of system development. $o& is customer feed"ac5! such as requests for ne& requirements! handledM Technology The vendor should provide technology specifications that support the product (e.g.! data"ase! architecture! operating system! 2(P versus in.house! etc.). (ervices The vendor should descri"e the services offered and corresponding fees (if applica"le). i. Pro%ect 4anagement ii. ,onsulting iii. 4PI ,leanup iv. Integration v. Degal $ealth Record +efinition vi. Process Reengineering vii. 8ther Training The vendor should outline the training provided during and after implementation. Product +ocumentation The vendor should specify the product documentation that is availa"le and its formats. Implementation/4igration The vendor should provide detailed information a"out the implementation such as the timelines and resources required. +ata ,onversion i. If the system is not currently I,+.)1.,4/P,( or Eersion 01)1 compliant! descri"e plans for "ecoming compliant "y regulatory required dates.

$o& &ill the system handle "oth I,+.;.,4 and I,+.)1.,4/P,( dataM $o& long &ill the system support "oth I,+.;.,4 and I,+.)1.,4/P,( codesM iv. If the system uses 7eneral #quivalence 4appings (7#4s )! such as "et&een I,+.)1.,4/P,( and I,+.;.,4! descri"e ho& the integrity of the maps is maintained. v. +escri"e other data conversions (e.g.! document imaging! platform conversions). ". 4aintenance i. Gpdates/Gpgrades The vendor should provide information on ho& the system is maintained! including ho& often the updates/upgrades are applied! methods used (e.g.! remotely! on.site)! and "y &hom. ii. ,ompliance &ith 4eaningful Gse Incentive Requirements The vendor should provide its plan for addressing meaningful use on an ongoing "asis! including plans for achieving corresponding certification requirements. iii. #9pected Product Difetime The vendor should outline the e9pected time frame for the ne9t version requiring a different platform or operating system upgrade iv. ,ustomer (upport The vendor should outline the types of customer support pac5ages offered (e.g.! *=/>! &ee5day only)! methods of support (e.g.! help des5 or tic5ets)! and the tools used (e.g.! C11 num"er! e.mail! :e"."ased! etc.). v. #9pected Facility (upport The vendor should outline the num"er of full.time employees e9pected to support the product at the facility. ". Pricing (tructure i. Product (oft&are Pricing ). Price The vendor should provide the price of the proposed solution! "ro5en do&n "y application/module! including licensing fees. *. ,ost of 8&nership ("rea5do&n over a certain num"er of proposed contract years) A. 8ther ,osts (maintenance! upgrades! consultation and support fees! post.implementation training and services! travel! etc.) =. +iscounts (availa"le discounts such as those "ased on participating as a "eta site) ii. Invoicing (fee schedule and terms) iii. Return on Investment iv. 2cceptance Period The vendor should outline the terms for validating the product after implementation and the refund policy ". :arranty The organization should request a copy of the &arranty! as &ell as ho& it is affected "y maintenance and support agreements after the implementation period
ii. iii.

(ections 0 and ? are to "e completed "y the facility. Eendor Requirements and Instructions a. RFP Ouestions The facility should provide the name and contact information of one person to &hom all questions concerning the RFP should "e directed. 7enerally! questions a"out the RFP must "e su"mitted in &riting &ithin a given time frame! and the questions and ans&ers are distri"uted to all vendors responding to the RFP. Provide the preferred method of contact! such as fa9 num"er or e.mail. ". Response Format! +eadline! and +elivery c. ,ontract +uration The facility should request that the vendor to disclose ho& long the returned information &ill "e considered valid. ). Terms and ,onditions a. ,onfidentiality (tate confidentiality rules in regard to the information the facility disclosed in the RFP as &ell as the rules pertaining to the information provided "y the vendor). ". Information 2ccess The facility should descri"e &ho &ill have access to the returned RFP and for &hat purpose. c. id #valuation and 3egotiation The facility should "riefly descri"e the evaluation process and the deadlines and provide the appropriate information if vendors are allo&ed to negotiate after the evaluation is complete. d. Formal Presentation The facility should descri"e process and format requirements if the vendor is invited to present the soft&are product suite. e. 2cceptance or Re%ection The facility should descri"e ho& the vendor &ill "e notified regardless of &hether the product is selected or not. f. ,ontract Provisions The facility should note the sections of the RFP response that can "e included in the final contract. g. Type of ,ontract The facility should let the vendor 5no& if this &ill "e firm fi9ed price! cost plus fi9ed fee! a time and materials! or other type of contract. 2lso refer to certification requirements and $ealth Devel (even ($D>) #$R (ystem Functional 4odel (#$R.( F4) for other 5ey requirements/features.
). Article citation: American Health Information Management Association. "RFI/RFP Template (Updated ." (!pdated "!l# $%&%

,opyright P*1)1 2merican $ealth Information 4anagement 2ssociation. 2ll rights reserved. 2ll contents! including images and graphics! on this :e" site are copyrighted "y 2$I42 unless other&ise noted. Kou must o"tain permission to reproduce any information! graphics! or images from this site. Kou do not need to o"tain permission to cite! reference! or "riefly quote this material as long as proper citation of the source of the information

is made. Please contact Pu"lications to o"tain permission. Please include the title and GRD of the content you &ish to reprint in your request.