« NHS IT Project: media responses to the NAO report | Main | Mapping Health and Social Care »

Smartpen: rewriting the record

smartpen.jpgFinding the right data device for clinicians resembles the search for the Holy Grail, as I have commented before.

I continue to like pen and paper-which provides me with the freedom to use a mélange of words, diagrams and runes. Perhaps that's why I was so taken by Datapulse's Smart Pen, when I came across it at a recent IT Directors event.

Smartpen allows pen and paper to be integrated with IT. You write with ink in the normal way and a tiny camera records the pen's strokes which you download onto a PC. You then have a hard copy and a digital copy that can be integrated into an Electronic Patient Record accompanied by a full audit trail.

It could digitise readings of vital signs, such as heart rate and temperature, that are written on a chart at the foot of a patient's bed. Time and date could ensure regular readings are taken, perhaps alerting staff if they are not.

Find out more on the Datapulse site.

Read about Smartpen in Healthcare (PDF).

TrackBack

TrackBack URL for this entry:
http://www.futurehealthit.com/mt/mt-tb.cgi/226

Listed below are links to weblogs that reference Smartpen: rewriting the record:

» Smartpen: rewriting the record from FutureHIT - Speculations on the Future of Health IT
A post in Colin Jervis' Future Health IT blog entitled Smartpen: rewriting the record reminded me of insights I gleaned from John Seely Brown and Paul Duguid's book The Social Life of Information, which I read just before starting the Master of Science... [Read More]

» Quickie: Follow-up on Smartpen: rewriting the record from FutureHIT - Speculations on the Future of Health IT
I wrote recently about the blog post on Colin Jervis's FutureHealthIT blog about the SmartPen (Future Health IT: Smartpen: rewriting the record). I tracked down a fairly detailed albeit two-year-old description of the underlying Anoto technology on the... [Read More]

Comments

I use the Logitech Pen which is similar. The U.S.'s Indian Health Service has developed some applications around this technology. My opinion is that it is NOT enterprise technology. It is good for personal use but I would be reluctant to use it in the enterprise with demanding users in demanding environments.

[Comment edited by FHIT].

I'm liking what I see about the adoption of these pens. I was wowed by them about 18 months ago in a sort of "it must be magic" way. Now we have the healthcare sector trialin them.
Anony-mouse, can you explain why you still see barriers to enterprise use?
Thx
ClickRich

I second ClickRich's question to Anony-mouse. I'm open to other points of view, but for myself, I looked at this and thought, "What a breath of fresh air! A high-tech data capture device that backs itself up (on paper) as it records information digitally, is not restricted to any particular Unicode page (so you can write in English, Japanese, Chinese and Farsi on the same page), and still works even when its high-tech affordances are broken!"

I haven't looked at the specs in detail yet, but I do wonder about NEMA4 compliance (or whatever equivalent standard there is in the kinder, gentler parts of the world). Does anybody know: Is it a potential "vector", as an ID doc once said disapprovingly of my Nokia 770?

I was quite excited about this technology as well. It seems like an excellent input device that would easily work into the flow of a clinic/office.


However, it really doesn't do so well for interaction with the data...not like a stylus and a tablet PC which can change content per your entry.


Now there may be ways around that..such as the audio that is used with the Fly Pen, or perhaps something else.


Still it is excting.

Re: IHS link:
http://www.anotogroup.com/cldoc/13868.htm?__style=print

Re: Non-enterprise class solution.

Pro's:
+ Paper-based - familiar "UI"
+ Can integrate with forms
+


Con's:
- Poor and limited vendor support from "VARs" like Logitech - just try and get a timely response to basic issues (.NET "timer" errors, dll conflicts due to a mix of COM and .NET)
- Pens have limited battery life and only charge in singular USB cables (no multi-upload charging stations
available)
- Pen settings can be changed by users making them like thumb drives with information that can leak out of your organization
- Basic encryption only
- Requires training of the user and application to learn the writing "norms"
- IOTag libraries/content management don't exist (at least when I looked at it)... therefore, a central PC was required for each user to manage their profiles, not conducive to many users' workflows and it may not be compatible with the forms software
- User profile roaming for pen recognition doesn't exist (at least when I looked at it) - therefore you always had to go back to your PC for recognition...
not conducive to many users' workflows
- Dictionaries for the user don't roam with the user (at least when I looked at it) - therefore you always had to go back to your PC for recognition... not conducive to many users' workflows
- relatively costly HP/Anoto developer's kits (printer, paper, SDK - respectively)
- Costly consumables with very limited providers - ink and paper(limited number of providers of the special ink for the pens... DON'T COUNT ON LOGITECH FOR ANYTHING and their forums are the ONLY help. Their support couldn't even tell me that Cross offered the refills and if they were compatible. They also weasel out of support when you don't buy the consumables from them). This leads me to question the long-term viability of this solution (are there enough OEMs of the Pen and ink). If it goes the way of the dinosaur, will HP continue to support generation of the printing pattern on a users' custom forms solution or will changes in platforms (e.g., move from Win2K3 to future Windows Server break the applications, will printer drivers still be available).
- Further evidence of the long-term viability issues (Annoto is tiny and now HP has "transitioned" support
- Note to HP customers:
HP no longer sells the HP Forms Automation System software, hardware or other components. HP has transitioned the Form Automation System solution to selected partners that are now licensed and fully capable of delivering their own solution to the market. These selected partners are..."
http://h30046.www3.hp.com/ipgformsautomationsystem.php


Recommendations:
* Through good programming/ architecture, a developer could use context-sensitive areas to signigicantly boost recognition and tune QA capabilities
* Use bar codes on the paper and scan/index it for back-up of the paper
* Carefully consider edits to "existing" captured form data entry sessions
* Use IOTags consistently (develop enterprise profiles and a means of transporting that profile with the user and allow users to develop their own tags for their
documentation)
* Consider using a basic system for patient consent capture and storage
* Develop as portable of code as possible
* Attempt to get printer driver code and HP SDK and Annoto SDK source code in escrow as a risk mitigation strategy

Kevin- wow, super run down.

Despite the immediacy of the pen as input device, I wonder if OCR software and well designed forms (with their software counterpart/parcer) would do as well, or better.

OCR (I'm thinking flatbed scanner type stuff, not optical pens) technology has been around the block and seems more flexible. Plus, processes/forms developed for an OCR input, might be easily updated to the pens if/when they get better.

Still not interactive.

John - you're right on with my nebulous comments. The comments under RECOMMENDATIONS, "Through good programming/ architecture, a developer could use context-sensitive areas to signigicantly boost recognition and tune QA capabilities". This comment really means that a good developer will use well-designed forms that support a specific process and within the context of the section of the form, they can tune the OCR capabilities to recognize the text better. For example, in a medications section of a form, only direct the character recognition logic/dictionary to medications. If it is a form for mycardial infarct, direct the form to preferentially weight cardiac drugs (if you have a controlled vocabulary and metadata model that supports this level of specificity).

Computer-generated characters are usually much more easily recognized as compared with recognition of human-written text. With either, the recognition rates REQUIRE some level of QA. I believe 2 levels of QA are adequate. The first is presented to the user when the form is recognized (uploaded, in the case of a pen). This would interact with the user much like Microsoft Word interacts with the user with spell-check. The second level of QA is validation of the patient, form filing area (i.e., which electronic "tab" in the chart is it to be filed under), and final validation of any information (perhaps placing some tighter bounds around text acceptance).

Scanning of forms has been around for a long time. I have personally been involved in 3 implementations of this (outpatient and inpatient). Usually, the forms are inventoried (and consolidated), standardized, all are given a unique ID supported by a pre-printed bar code to speed filing/indexing, the text standards are established for OCR (e.g., Times New Roman 9pt with "x" kerning, Arial 10pt), the scanning model is established for STAT documents and all others by document type (doc type includes tracings, operative reports, etc.) - including what scanners, where, who, what QA, what indexes, what electronic filing rules, etc, then pilot, then fix the issues and rollout.

Widely decentralized scanning usually causes increased expense in the form of equipment/software, user training, and data quality issues. Minimizing the number of necessary scanning and QA queues (in other words, specialization) is a better way to go in most cases. The major drawback is a lack of staffing and equipment redundancy in cases of outages, maintenance, or a disaster.

Kevin- Exactly. Intelligently designed forms would help tremendously in figuring out what folks are writing...your example is well put. I assume checkboxes, fill in the blanks, and other design features would also help limit the amount of "guessing" OCR software would need to do.

I guess there is no way around the 2x QA, and its corresponding staffing needs.

I wonder if the systems that convert faxes to email, with an OCR component, would help with resources and organizational flow.

I'm new to all of this (looking at studying Medical Informatics) but I do appreciate a good template or two :-)
My Hipster PDA

John -
The limitation with checkboxes or fill-in-the-blank on paper that there is no logic checking (e.g., do 2 entries on the form cancel each other out, do 2 entries make symantic sense) and also with checkboxes, there is no ability to dynamically update information based on the patient (e.g., patient's problems, procedures, enrollment in chronic care management guidelines).

Applications that use OCR usually use (host) the common "engines". These engines are typically plugged into (hosted within) fax and scanning applications via an API and the the hosting applications, if well designed, they also have workflow components or can work with a workflow or business process management engine to allow for rules-based routing (e.g., a user's skills - such as route to a nurse managing chronic CHF, route to a patient's primary care physician).

Kevin-

Interesting, I hadn't thought of the semantic probs of those limited input fields.

Bringing this back around...I suppose that would be true for the Smartpen forms as well.

I suppose the Smartpen is not currently shipping with workflow apps...or Smartpens have an API that someone like you customizes into a workflow app? Pehaps FAS does that.

Thanks again for your answers. Feel free to disregard if you don't have the time.

John

John - correct - SmartPen forms have the issue but at upload, you have the user's attention and could "force" them to go through the issues (pro's and con's to this design... much like too many required fields on a data entry form). The SmartPen has some new features for initiating some basic tasks, such as send to e-mail (Outlook). Based on the capabilities of the other applications, very rudimentary workflow could be initiated out of the box. FAS has some more robust features, but depending upon the requirements of the users/ administrators involved in the process, they may not be enough. Based on my initial review, the basics are there to meet the 80/20 rule - ASSUMING USERS ARE AMENABLE TO REENGINEERING TO THE PACKAGE and not changing the package to meet their exact (and often overly complex) requirements. Many companies have great experience with forms automation and standard workflow processing, it is really in your data package design, event model design (triggers, encounter indicators, security around viewing of these, managing the form's state), and the complexity of your workflows (some great research has been done by academics with practical applications - look up YAWL)

Pragmatic advice for sure.

Thanks for the YAWL reference. YAWL is on SourceForge, so I may just check it out.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)