Guidelines for submitting articles to Health Management Technology
HMT is written for senior executives in hospitals, healthcare organizations, integrated delivery networks, managed care organizations and health plans, and physician practices and IPAs. Our readers are CEOs, CIOs, CFOs, CMOs, CTOs, IT directors and managers, and other decision makers working in information technology in healthcare settings.
Before you contact us
Health Management Technology is available on the Web – at www.healthmgttech.com – and in print. In addition, our editorial calendar and editorial submission guidelines are posted on our Web site, as is a breakdown of our circulation. Please read the publication, the guidelines, the editorial calendar and the circulation statement before contacting us, so that you understand our audience makeup and what types of editorial contributions we accept.
What we are looking for
FEATURES: Feature articles explore state-of-the-art in healthcare information technology. We examine issues and questions facing executives as they make technology decisions for their organizations – facts they need to know, obstacles, technology trends, available options, innovations to consider. We cover a wide range of topics described in our editorial calendar and we welcome suggestions for new topics not on the editorial calendar. The majority of our features are end-user or vendor-contributed, solutions-based, real-world application stories in a case-study format. We also publish tutorials that discuss technology developments important to healthcare organizations (i.e., hospitals, healthcare organizations, integrated delivery networks, managed care organizations and health plans, and physician practices and independent practice associations). Articles should be focused on end-user solutions, or solutions provided by service providers to end-users.
COVER STORIES: Cover stories are expanded case histories and are selected from abstract proposals submitted for a given month and topic. Do not submit a cover story proposal; we will determine from the abstracts we receive for the planned topics in any given month which one warrants cover story treatment. Cover stories generally run 1,500-2,000 words, with the vendor also providing high-quality photography of the customer who is the subject of the article. Among the criteria we use for selecting cover stories: Does the implementation have enough scope and variation to warrant expanded treatment? Will the implementation appeal to a wide range of end-users? Have we covered the topic with a cover story within the past 12 months? Has the vendor provided a cover story within the past 12 months? Will the vendor commit to the extra resources necessary to provide the type of article and photos necessary?
Thought Leaders. Written by an industry leader, often a vendor and sometimes an end-user, this front-of-the-book feature offers an opportunity to editorialize on a hot technology topic. The Thought Leaders column is typically about 1,200 words in length. Query Editorial Director Ken Anderberg at [email protected]. We have detailed Thought Leaders guidelines available.
PRODUCT SECTIONS: New product information should be sent to the Products Editor ([email protected]). This will ensure that it gets handled correctly. If you send it to the wrong editor, it may be misplaced. We publish New Product Announcements relevant to our healthcare end-user audience. We do not conduct product testing or write product reviews. Please send your new product announcements as soon as the product is shipping, and do not try to target it to a specific issue.
Calling to follow up on product press releases does not help or speed up the process. Please do not follow up by phone to – check on the status – of the product submission. Please submit files of less than 3 megabytes. NOTE: Do not send screenshots or company logos as artwork.
FEATURES: Getting started
First, send us an abstract proposal. After defining the topic, write two or three paragraphs describing what you want to say in your article. Make sure that you identify, with the abstract, the month and editorial subject from our editorial calendar that you feel the article fits in, as well as the vendor or end-user supplying the article.
DO NOT submit an abstract unless the companies involved (vendor and customer, if appropriate) have agreed to have the article published.
Send the proposal to the editorial director (e-mail is the best way) at least 14 weeks prior to publication date (e.g., Dec. 15 for the April issue). Our policy is to review all proposals at the same time shortly after the abstract deadline date and to inform all potential contributors whether or not their abstract has been accepted for development into a feature. Please do not follow up by phone to “check on the status†of the abstract.
Important: Please submit with your abstract the vendor name, address, phone, fax, contact person for reader inquiries, e-mail and Web addresses.
Writing the article
CASE HISTORIES should be solution-based, providing practical and useful information to healthcare organization end-users (i.e., hospitals, healthcare organizations, integrated delivery networks, managed care organizations and health plans, and physician practices and independent practice associations). A simple and effective formula is this: Here is a problem we had; here is the way we solved it; these are the products and techniques we used; this is how we’re working now.
A case history should not be more than two years old and should include all the elements of the solution, not just the vendor’s products (if there are more elements than one). We prefer third-person accounts, so it is generally better to include quotes from the end-user, rather than use that person as the author. Case studies should not carry the vendor’s byline, since the vendor and products are mentioned in the story. Also, quotes from the vendor generally are inappropriate for case histories and are usually deleted from manuscripts. A case study should focus on just ONE end-user situation, not on multiple end-user examples. Here is some of the information we would like included in the article:
- Describe the problem solved and the improvements made. But don’t tell the reader; show him. Be descriptive of an actual situation that illustrates the point, rather than simply making the point, as in “The solution provides security.” Put that statement in context with an actual example of how security was provided for the customer.
- Provide a straightforward presentation on how a solution was implemented, what the challenges were and what the results are, so that IT decision-makers will have at least most of their questions answered. Remember that the technical side of the implementation is the most important element of a case study, providing useful information to CIOs, and IT and department managers who want to know how the network is configured, what changes were made, how the changes affected the network, etc.
- Was there a particular moment or occurrence that crystallized the need for the solution? That moment would make a good anecdotal lead.
- How was the problem increasing expenses, hindering operations, causing staff to be unproductive? Again, use examples to illustrate your points.
- Was the solution interoperable with other components of the network? If not, what changes were made to provide interoperability?
- When did corrective action first start and how was it accomplished?
- How was a final solution selected? Site visits? Vendor demos?
- How many products were reviewed before deciding?
- How long did the implementation process take? What were the steps?
- Describe the most important components of the solution, or the network where the solution was installed: hardware, software, networks, consultants, training, etc. This can best be done by having the customer talk about situations where these parts of the solution came into play.
Also:
- What was the approximate cost of all components of the solution?
- What was the cost justification and the ROI?
- Who had to approve the purchase or installation?
- How many staff and/or customers are served by the system?
- What are the security and business continuity issues addressed by the solution, if applicable?
- What are the benefits, in terms of: savings, productivity, customer care or service, etc.?
- Are enhancements planned?
- Include any anecdotes that speak to the value and benefits of the solution?
- Please include quotes of principals of the subject company throughout the article to describe the process.
- Do not include quotes from the vendor or vendor partners.
The importance of “Warts.” Warts are journalistic imperfections in an article – not errors but rather negatives about the subject. Articles that paint too rosy a picture often are dismissed by readers as self-promotional. Articles that include “warts” become more believable by readers because the warts provide a dose of realism and truth that says to the reader, “We are presenting the problems associated with this solution, as well as the benefits.” The article immediately becomes more believable, as a result. A journalist would seek out these imperfections in order to write a more balanced article. We encourage you to include warts in your article whenever possible.
Manufacturing quotes in case histories: Please don’t. Interview the subject and use real quotes. An example of what we see a lot: “XYZ company did a fantastic job with the implementation and their products are saving us lots of time and money.” These types of quotes do not lend any useful information to our readers, and generally will be deleted from the article.
Contact information. In addition to contact information for the vendor submitting the article, we will need the name, phone number and e-mail address of a person at the company that is the subject of the case history. This person preferably should be the one interviewed for and quoted within the article. Editors routinely call these contacts to verify information or to ask additional questions. Failure to provide this contact information can result in your article being turned down.
The Tutorial
A second type of story is a tutorial, which examines a new, basic or advanced technology in a new or updated context. A tutorial style article should still be readable and, where possible, cite specific examples and cases. A tutorial can carry a byline from a vendor representative, but the vendor’s products will not be mentioned in the article.
Please do not submit an opinion piece as a tutorial, and remember, we want discussion of solutions, not problems. Your article should explain how the technology is used by and benefits the end-user. Avoid too much historical background. Do not criticize competing technologies; instead focus on the features, implementation, benefits, etc., of the technology of your focus.
Tutorials should be solution-based, providing practical and useful information to end-users. Also:
- Provide a straightforward presentation of the technology/solution discussed, so that IT decision-makers will have at least most of their questions answered.
- What are the cost and staffing implications of the technology/solution being discussed?
- Is the solution interoperable with other components of the network? If not, what changes must be made to provide interoperability?
- Describe the most important components of the technology/solution.
- What are the benefits, in terms of: savings, productivity, customer care or service, etc.?
Articles that are self-serving or recite the technical specifications of a particular product are unacceptable. The article should not serve as a thinly disguised promotion for a product or company.
Any submission of articles must be exclusive to Health Management Technology. We generally do not accept articles that have been published in another trade journal, newspaper, periodical, on the Web, company literature or conference proceedings.
Acceptance Frequency Policy
In order to be fair to all potential contributors, we limit the frequency of articles accepted for publication from any one company to no more than one article every four months.
Length
Our feature stories generally run from 700 words to 1,500 words.
Submission
If your article is accepted for publication, it will be assigned a file name to use in future references. Please be aware that your manuscript will be edited for style, space requirements and ease of reading. We can accommodate your article and graphics on a CD or as an attached file to an e-mail message (preferred).
Important: Make sure the manuscript you send us has the name and address of a contact person within the vendor company submitting the article to whom we can send reader inquiries.
Photos and illustrations
Photos and artwork help to set a tone for articles, and provide important visual interest. We encourage you to provide photos and/or artwork for the article. For case histories, we prefer photos at the customer site, preferably including the main person who is quoted (no head shots, please). Artwork, graphics or photographs should be high-quality photographs, transparencies, 35-mm slides or electronic files. Line drawings such as tables, charts or schematics also are acceptable. Graphics may be submitted in digital format or via hard copy. The graphics should be in Adobe Photo Shop- or Adobe Illustrator-compatible TIF, JPG and PPT files. EPS is not recommended. The best quality comes in 300 dpi high-resolution or higher.
Important: Do not embed graphics, artwork or photos in the Word document containing the article. Also, include captions with all photos and artwork.
Contact us
Editorial Director
To propose feature articles, send a short abstract first. Indicate the Month and Focus Subject the article is intended for in the subject line of your e-mail.
Products editor
Send new product announcements.
Indicate “New Product” in the subject line of your e-mail.
Product Submission Guidelines:
Health Management Technology
2500 Tamiami Trail N.
Nokomis, FL 34275
Phone: (941) 966-9521
FAX: (941) 966-2590
{jcomments off}
