|  
|
Contents
Introduction
FP32 is the newest generation of periodontal software
from Florida Probe Corporation. FP32 can be considered a periodontal
charting package, as well as a software interface to the custom
periodontal probes manufactured by Florida Probe Corporation.
This white paper describes options for incorporating the functionality
of FP32 into other software environments.
Back to table of contents
Target Audience
This document is intended for software engineers who are familiar
with application development in Win32™ environments.
Terminology
Throughout this document, the following terms may be used:
FPC: Florida Probe Corporation, or contractorsworking with FPC
to develop the FloridaProbe and related products.
External Integrator: A developer or team of developers working
under NDA with FPC to integrate functionality from the Florida
Probe into their own product line.
Host Application: The application controlled by the external
integrator that must integrate Florida Probe functionality.
Back to table of contents
Integration Levels
There are several different possible levels of integration with
FP32. Which level of integration an engineer chooses can have
an impact on the amount of work required by both FPC and the external
integrator. The likely integration levels that we have anticipated
are:
-
Florida probe functionality only. Patient tracking and user
interface are handled entirely by software developed by the
external integrator, but data is collected using the Florida
Probe hardware.
-
Charting and probing functionality only. The Florida Probe
hardware is used to collect periodontal data using FP32. FP32
is used to interface with the Florida Probe Hardware and to
chart and display periodontal data as it is recorded. FP32
may also be used to print reports. Storage of patient records
is still handled by software developed by the external integrator.
-
Full functionality on demand. FP32 is launched when necessary
and is supplied with a limited amount of patient information
which correlates records in the FP32 database with records
in software developed by the external integrator. FP32 is
used for all periodontal data collection, and no data is returned
to the external software, other than perhaps a termination
signal when a probing session is complete.
Out of the three previous integration levels, we strongly recommend
either option #1 or option #3, because they require little modification
to software from FPC and software from the external integrator,
and they do not require the development of a complex protocol
for data transfer.
Back to table of contents
Florida Probe functionality
only
Some external integrators with a line of charting software
already developed may wish to incorporate no FPC software other
than the bare minimum necessary to operate the periodontal probing
hardware. For integrators with these needs, FPC has developed
three simple options, an interface DLL,
an interface ActiveX component, and source
code integration. The DLL and the ActiveX component contain the
same functionality, but exist in tandem in order to provide developers
with as wide a variety of integration options as possible. Applications
that are based on C or C++ will integrate easily and quickly with
the DLL, as will applications developed under languages that support
DLL integration such as Microsoft Visual Basic and Borland Delphi.
Some application development environments offer more robust component
integration through ActiveX components (formerly known as OCX
modules).
The primary difference between the ActiveX component and the
DLL is the programming model.
Back to table of contents
|
|
|
|
The Interface DLL
The Interface DLL provides a
simple interface to the Florida Probe hardware. Both the
footswitches and the probe depth reading can be determined using
the DLL, but all data must be collected from the hardware through
polling by the host application. There is no callback functionality
in the DLL. If a user presses a footswitch, for instance, the
host application will not receive any message to that effect,
but will be able to determine that the footswitch has been activated
the next time the hardware is polled. This means that a host application
willbe required to implement all logic for determining when a
footswitch has been held down for a specified period, for
determining when leading and trailing edges on footswitches have
occurred, etc. Typical functionality exposed by the interface
DLL:
-
InterfaceInitialize() – instructs the software to initiate
a connection with the hardware.
-
InterfaceReady() – a predicate function for testing for
the availability of the hardware.
-
InterfaceGetFootswitches() – determines the current status
of the hardware’s footswitches via flags set in a single integer.
-
ProbeGetDepth() – determines the current probe depth and
returns it via a double-precision floating-point value.
The Interface ActiveX
Component
The ActiveX component provides the
same functionality as the interface DLL, but because of the encapsulated
model of ActiveX components, this component is capable of running
its own footswitch and probe monitoring thread in the background
using the apartment threading model. Whenever a footswitch event
is detected, the component sends an event to the host container
with a message indicating what has happened. This eliminates the
need for a host application to maintain its own probe polling
thread and makes the host application much simpler to develop.
Footswitch events also eliminate the need for the host application
to ‘remember’ the last known state of the footswitches for detecting
leading edges, trailing edges and hold events. As with the interface
DLL, when changes are made to the hardware or software at FPC,
they can be easily incorporated into host applications by simply
replacing the component and not changing any code in the host
application. Typical functionality exposed by the ActiveX
component:
-
No initialize (the component automatically initializes
itself)
-
InterfaceReady() – a predicate function for testing for
the availability of the hardware.
-
InterfaceGetfootswitches() – determines the current status
of the hardware’s footswitches via flags set in a single integer.
-
ProbeGetDepth() – determines the current probe depth and
returns it via a double-precision floating-point value.
-
FootswitchEvent – an event that indicates that some footswitch
event has occurred.
Source Code Integration
Source code integration is an option that exists for programmers
who are comfortable with C++ development. External integrators
have the option of simply acquiring the relatively simple source
code used in the DLL and the ActiveX components (they share an
identical code base) to communicate with the Florida Probe hardware.
This source consists of a single source file and a single header
file which describe a C++ object. This source code is a clear
example of the protocol used by FPC to integrate with the
hardware, and can be used as-is, or simply as example code for
directly integrating with the hardware from any language
which is capable of accessing a serial port. A major disadvantage
of using source code directly is that as changes are made
in the software and hardware at FPC, changes are not transferred
as easily to external integrators as they are with the interface
DLL or with the ActiveX component.
Back to table of contents
Charting
and Probing Functionality Only
Some external integrators may have large and complex applications
and wish to integrate the charting and probing functionality with
their applications but retain the capability of storing all patient
data within an external database. Under this model, the host application
would store all patient information, and at the appropriate time
it would launch FP32 and instruct it to collect periodontal data.
When FP32 has completed the periodontal data collection, it would
pass the entire data set back to the host application for storage.
FP32 may or may not be used under this scenario for printing patient
charts. For these integrators, a specialized protocol must be
developed for passing data back and forth between the host application
and FP32. This protocol will likely be unique for each host application,
and no such capability is currently built into FP32. A likely
method of communicating with FP32 from a host application will
be ActiveX Automation (formerly known as OLE Automation). FP32
currently exposes an ActiveX Automation interface, but since there
are currently no applications that require this method to communicate,
no extensive documentation is available on this interface mechanism.
Any external integrator wishing to use the ActiveX Automation
interface to develop a unique protocol should contact FPC to arrange
for the development of a custom gateway. Data handoff through
the use of custom pass files may also be a possibility.
Back to table of contents
Full Functionality
on Demand
For external integrators who are willing to entrust FP32 with
the task of storing patient periodontal data, a simple and abstract
level of integration is possible. Once the host application has
collected personal information about the current patient and has
determined that it is time to collect periodontal data, the host
application simply launches FP32 normally. The host application
then passes FP32 simple patient information, such as the patient’s
name, and a unique identification code (a ‘primary key’) for the
specified patient. This primary key is remembered by the host
application, and is used to correlate data stored by FP32
with data stored about the same patient in the host application.
When FP32 is launched under this model, it will not present the
user with the normal system of collecting personal information
about the patients, since that information is stored by the host
application. FP32 skips instead directly to the periodontal data
collection mode. Under this model, the user must be fully familiar
with the FP32 interface in order to collect periodontal data.
Major advantages of this model include simplicity and maintainability.
When changes are made to FP32, the host application need not be
affected. FP32 and the host application can be distributed independently,
and can be installed on the end-user’s system at different times.
Communication between the host application and FP32 may
occur through ActiveX Automation, or by simply passing the required
information to FP32 on the command line.
Back to table of contents
|
|
|
