Wordpress – one of the most popular CMS of today has won the Overall Best Open Source CMS award for the year 2009. The Open Source Content Management (CMS) Award is an initiative of Packt Publishing – a long time supporter and promoter of Open Source projects and concepts. Since the award was launched in 2006, the awards have become an important event in the Open source calendar.

A visibly pleased Matt Mullenweg, founder of WordPress, responded to the news, “The entire WordPress community is honoured to accept this award.” Mullenweg further added, “Every day thousands of new people are embracing WordPress to power not just their blog but their entire website and community without compromising on usability or scalability as you would with a legacy CMS.”

MODx and Silverstripe tied for the first runner up position, after Wordpress.
ImpressCMS won the Most promising CMS Award, while, Pixie and Pligg tied for the first runners up.

Other winners included:
Drupal: (inaugural) Hall of Fame award, Best Open Source PHP CMS
Joomla: 2nd Runner Up (Open Source PHP CMS)
Plone: Best Other Open Source CMS

The award witnessed over 12,000 nominations and around 23,000 votes across the five categories.

Complete details are available on the Packt Publishing website.

Zend Search Lucene is a fulltext search engine written in PHP. It is an implementation of the java-based Apache Lucene in PHP. Lucene Search is a part of Zend Framework (ZF) and large chunks of ZF can be used as a standalone and integrated into any existing application.

Before getting into the minute details of ZSL, we should first understand what a fulltext search is. It is a combination of indexing content and then conducting search. For ZSL, index is made up of documents and these documents, in turn, contain fields, which contain content that is queried. In general, web applications deal with databases for keeping contents, so index is nothing but a table/view and documents are records in the table.

However, ZSL is not limited to index tables. We can index HTML documents, XLS sheets, Word Documents, Power Point slides, PDFs etc.

Present day web applications store content in powerful RDBMSs like MySQL/PostgreSQL having native support for fulltext search. This leads to a genuine confusion about why should the development team invest in a third party library for fulltext search?

ZSL wins over MySQL (and most popular RDBMS) for several reasons:

• ZSL returns a ranked result-set.
• ZSL searches for keywords in indexed documents stored within the file system at the webserver compared to fetching content from the DB over established connections. This makes ZSL faster than conventional search.
• Fulltext search works with MyISAM storage engine only.
• If document size increases, performance of search decreases drastically because indexes are cached in RAM.
• INSERT in fulltext search table becomes very slow because of reformation of whole index.
• In MySQL, there is no configuration for stop words and tokenizers, while in ZSL we can define our own stop words and tokens.
• ZSL boasts of many advanced features like proximity search, wild card search, similarity search, range search, phrase queries etc.
• ZSL has simple but very powerful query syntax.

Let us see how ZSL works. As discussed above, ZSL first processes an index and then queries search. So let us create the index first:

//Function to create index.
public function createindexAction() {
	Zend_Search_Lucene_Analysis_Analyzer::setDefault(new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum_CaseInsensitive());
	$patientModel = $this->_getPatientTable(); //Instantiate object of patient table.
	$patientArray = $patientModel->fetchAllRecordsForIndex();

	//Specify the path where indexes will be stored on file system.
	$patientIndexPath = Zend_Registry::get('configuration')->patient_index_path; 

	$index = new Zend_Search_Lucene($patientIndexPath,true);	
	foreach($patientArray as $patientRow) {
		$index->addDocument($this->generateZSLDocument($patientRow));
	}
	$index->commit();
	$index->optimize();
	echo "Indexes created successfully.";
}

public function generateZSLDocument($patientRow) {
	$doc = new Zend_Search_Lucene_Document();
		
	// Field is tokenized and indexed, and is stored in the index.
	$doc->addField(Zend_Search_Lucene_Field::Text('PTPTNO',$patientRow['PTPTNO']);
	$doc->addField(Zend_Search_Lucene_Field::Text('PTPLN', $patientRow['PTPLN']);
	$doc->addField(Zend_Search_Lucene_Field::Text('PTPFN', $patientRow['PTPFN']);
	$doc->addField(Zend_Search_Lucene_Field::Text('PTPDOB', $patientRow['PTPDOB']);
	$doc->addField(Zend_Search_Lucene_Field::Text('PTPSSN', $patientRow['PTPSSN']);
		
	// Field is tokenized and indexed, but is not stored in the index.
	$doc->addField(Zend_Search_Lucene_Field::UnStored('PTCHRT', $patientRow['PTCHRT']);
	$doc->addField(Zend_Search_Lucene_Field::UnStored('PPPHPH', $patientRow['PPPHPH']);
	$doc->addField(Zend_Search_Lucene_Field::UnStored('PPPWPH', $patientRow['PPPWPH']);
	$doc->addField(Zend_Search_Lucene_Field::UnStored('PPPCPH', $patientRow['PPPCPH']);
	return $doc;
}

While adding the fields to the document, it is very important to specify the appropriate field types. Remember: larger the index, slower the response. Indexes are meant for searching and not for bulk storage.

If we have three fields in a table (file_id, file_name, file_data) and we want to fetch the name of the file whose content is the closest match for the query. Then, we should specify file_id as keyword, file_name as UnIndexed, and file_data as UnStored. The query will return the file_ids, file_names and later if we would be interested in fetching file content then we can hit to the db table to fetch the content of that particular file.

In order to understand different field types, just have a look at the following table:

How to Fetch from indexes created above:

public function patientsearchAction() {
	$field              =   $this->_getParam('fieldToSearch');
	$str                =   strtoupper(trim($this->_getParam('searchStr'))).'*';
	
	Zend_Search_Lucene_Analysis_Analyzer::setDefault(new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum_CaseInsensitive());
	$this->_helper->layout->disableLayout();
	$this->_helper->viewRenderer->setNoRender(true);
	if ($field == 'PHONE') {
		//pattern to remove any special char from phone number.
		$str = preg_replace('/[\s]*[(]*[)]*[-]*/', '', $str); 
		$query = new Zend_Search_Lucene_Search_Query_Boolean();
		$field    =   "PPPHPH";
		$queryPattern = new Zend_Search_Lucene_Index_Term($str, $field);
		$subQuery = new Zend_Search_Lucene_Search_Query_Wildcard($queryPattern);

		//Null specifis that this is neither required nor prohibited.
		$query->addSubquery($subQuery, NULL); 
		$field    =   "PPPWPH";
		$queryPattern = new Zend_Search_Lucene_Index_Term($str, $field);
		$subQuery = new Zend_Search_Lucene_Search_Query_Wildcard($queryPattern);
		$query->addSubquery($subQuery, NULL);
		$field    =   "PPPCPH";
		$queryPattern = new Zend_Search_Lucene_Index_Term($str, $field);
		$subQuery = new Zend_Search_Lucene_Search_Query_Wildcard($queryPattern);
                              $query->addSubquery($subQuery, NULL);
	} else {
		$pattern = new Zend_Search_Lucene_Index_Term($str, $field);
		$query = new Zend_Search_Lucene_Search_Query_Wildcard($pattern);
	}
	
	$hits = array();
	
	if ($query) {
		$index = new Zend_Search_Lucene(Zend_Registry::get('configuration')->patient_index_path);
		$hits = $index->find(strtoupper($query));
	}
            
	$PatientArray = Array();
	$totalRecords = count($hits);
	$i = 0;
	foreach ($hits as $hit) {
		$PatientArray[$i]['PTPTNO'] = $hit->PTPTNO;
		$PatientArray[$i]['PTPLN'] =  $hit->PTPLN;
		$PatientArray[$i]['PTPFN'] = $hit->PTPFN;
		$PatientArray[$i]['PTPDOB'] =  $hit->PTPDOB;
		$PatientArray[$i]['PTPSSN'] = $hit->PTPSSN;
	}
	$jsonData = Zend_Json::encode($PatientArray);
	$this->_response->appendBody($jsonData);
}

ZSL index segment is not updatable by nature so adding a new document to an index always generates a new segment. This in turns decreases the index quality. So, in order to increase the performance, optimize the index which actually merges the indexes.

//Function to update index. This function is called for both add/edit patient.
public function updateindexAction() {           
	$patientIdToUpdate = $this->_getParam('PTPTNO');
	Zend_Search_Lucene_Analysis_Analyzer::setDefault(new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum_CaseInsensitive());
	$patientIndexPath = Zend_Registry::get('configuration')->patient_index_path;
	$index = Zend_Search_Lucene::open($patientIndexPath);
	$hits = $index->find('PTPTNO:' .$patientIdToUpdate);

	//Delete index document for the updated patient.
	foreach ($hits as $hit) {
		$index->delete($hit->id);
	}

	$patientModel = $this->_getMpatTable();
	$patientArray = $patientModel->fetchPatientById($patientIdToUpdate);
	$index->addDocument($this->generateZSLDocument($patientRow));
	$index->commit();
	$index->optimize();
	echo "Indexes updated successfully.";
}

Few quick points to be aware of:

1. Index quality is completely determined by number of segments.
2. Index size is limited by 2GB for 32 bit platform.
3. Index optimization is a process of merging several segments into one.
4. Minimum length of search word is 3 but is configurable.

The blog post is based on excerpt of a session by Ankur Aeren on Zend Lucene Search made at OSScamp Delhi September 2009.

The OpenSQL Camp series of unconferences is organised by the Open Source Databases Community worldwide. These camps are being organised since 2008.

OpenSQL camps are free events, formatted like unconferences (eg: BarCamp, OSScamp) – a judicious blend of spontaneity and pre-planning. The event of 2009 in Portland is targeted at users and developers of Databases and will see plenty of presentations and hackathons.

The event is scheduled for November 14-15 this year. Sessions will include talks on Sphinx, MySQL, SQLite and much more. Around 120 participants are expected at the camp.

November 13th, 2009
6PM - Midnight (Dinner party)
Old Town Pizza, 226 NW Davis
Portland, Oregon 97209

November 14th and 15th, 2009
9AM - 5PM (OpenSQL Camp)
Souk, 322 NW 6th Avenue, Suite 200 (between Everett + Flanders)
Portland, Oregon 97209

To make a successful event, the organisers need to focus on organising the event and planning the logistics. To keep it free for participants, they need support from the Industry. OSSCube is proud to be a sponsor of OpenSQL Camp Portland 2009, along with the likes of Facebook, Google, Sun MySQL, Open Query, and O'Reily.

More details on: http://opensqlcamp.org/Events/Portland2009/
OpenSQL Mailing list - http://groups.google.com/group/opensqlcamp
OpenSQL on Twitter - http://twitter.com/opensqlcamp
OpenSQL on IRC - #opensqlcamp on http://freenode.net/

Electronic prescribing or “e-prescribing” is simply an electronic way to generate prescriptions through an automated data-entry process utilizing e-prescribing software and a transmission network which links to participating pharmacies.

A more formal definition could be
E-prescribing means the transmission, using electronic media, of prescription or prescription-related information between a prescriber, dispenser, pharmacy benefit manager, or health plan, either directly or through an intermediary, including an e-prescribing network. E-prescribing includes, but is not limited to, two-way transmissions between the point of care and the dispenser.

It is estimated that approximately 7,000 deaths occur each year in the United States due to medication errors. These errors are predominately due to hand-writing illegibility, wrong dosing, missed drug-drug or drug-allergy reactions. With approximately 3 billion prescriptions written annually, which constitutes one of the largest paper-based processes in the United States, the writing of prescriptions can be streamlined and made efficient by using an e-prescribing system. Also, e-prescribing could be the solution to improve patient safety and reduce medication costs due to better formulary compliance also improving utilization of generics.

The benefits of ePrescribing are spread across all participants in the healthcare system, including physicians, office staff, patients, pharmacies, and health plans service providers.

Providers benefit from ePrescribing by:

• Obtaining real-time information about potential drug-drug and drug-allergy interactions. This minimizes calls from pharmacies and reduces potential adverse drug events.
• Reducing handwriting interpretation errors, estimated to cause 9% of all medication errors.
• Seeing plan formulary requirements (prior authorization, quantity restrictions, non-covered drug, and drug tier) at the point of care, giving the patient faster access to cost-effective care.
• Seeing a patient’s dispensed drug history, thereby enabling the prescriber to make clinically appropriate decisions at the point of care.
• Knowing when an FDA Safety Alert has been issued, and allowing them to generate a report of all patients on the drug without needing to pull patient charts.
• Increasing the convenience and efficiency of the prescription-writing process.

Office staff benefit from ePrescribing by:

• Reducing calls from pharmacies regarding non-covered medications and handwriting questions.
• Speeding the prescription renewal process by reducing the need to pull patient charts. Case studies suggest a savings of 1-2 hours/day for office staff.
• Eliminating calls from patients who are requesting an alternative covered medication or need the prescriber to request prior authorization.

Patients benefit by:

• Having lower out-of-pocket costs when prescribers respond to ePrescribing formulary messages
• Saving time at the pharmacy by having prescriptions sent prior to patient arrival, and reducing the potential for two trips because prescribers more frequently adhere to health plan requirements.
• Reducing potential for adverse drug events caused by drug-drug or drug-allergy interactions, mistaken handwriting, or incorrect dosage.
• Increasing compliance with prescribed treatment because care is cost-effective and convenient.

Pharmacies benefit by:

• Reducing phone calls to physicians regarding handwriting interpretation, non-covered drugs, and prior authorization requirements.
• Improving customer relationships by speeding the time it takes patients to obtain prescriptions.
• Reducing data entry when prescriptions are received electronically.
• Reducing potential errors caused by handwriting misinterpretation and keystroke errors.

Payers/Employers benefit by:

• Maintaining affordability by increasing utilization of generic and preferred brand drugs.
• Reducing costs associated with adverse drug events.
• Increasing patient compliance with prescribed treatment plan.
• Increasing provider efficiency by allowing providers to spend more time on patient care.

A “qualified” e-prescribing system must be capable of performing all of the following functions:

• Generating a complete active medication list incorporating electronic data received from applicable pharmacy drug plan(s) if available
• Selecting medications, printing prescriptions, electronically transmitting prescriptions, and conducting all safety checks (safety checks include: automated prompts that offer information on the drug being prescribed, potential inappropriate dose or route of administration, drug-drug interactions, allergy concerns, or warnings or cautions)
• Providing information related to the availability of lower cost, therapeutically appropriate alternatives (if any)
• Providing information on formulary or tiered formulary medications, patient eligibility, and authorization requirements received electronically from the patient’s drug plan

To get started with e-prescribing, please take the following steps:

1. Decide whether you wish to choose a stand-alone e-prescription software or a full EHR or EMR system which includes e-prescribing functionality.
2. Choose an e-prescribing software vendor. The e-prescribing vendor will need to utilize a company which supplies the electronic prescribing network (hub or gateway for transmissions). There are a few different e-prescription networking companies. Among the industry leaders are SureScripts (http://surescripts.com/), RxHub (http://www.rxhub.net/index.html), and ProxyMed (http://www.proxymed.com/). It is unlikely that physicians would have any reason to have direct contact with the electronic networking vendor. SureScripts, the nation’s largest electronic prescribing network, provides a true, seamless electronic connection between physician offices and pharmacies. This network provides secure and reliable two-way transmissions between physicians and pharmacies. More than 85% of chain and independent pharmacies have tested and certified their systems to connect to the SureScript electronic prescribing network.
3. Install an internet connection; high speed is highly recommended.
4. Purchase hardware such as desktop PC’s, laptops, pocket PC’s, tablet PC’s , PDA’s utilizing a wired or wireless network.

Although there are a few barriers like cost, Prohibition on use of e-prescribing for controlled substances and Technical limitations, the benefits substantially out number them making e-Prescription highly recommendable.