ActiveX for Healthcare: A White Paper
ActiveX for Healthcare: A White Paper | |
|
| Microsoft Europe and
Microsoft Healthcare Users Group Europe - MS-HUGe
Increasing Interoperability and Lowering Costs with ActiveX™ for Healthcare A White Paper |
 |
| 1.0 HEALTHCARE INDUSTRY CHALLENGES Back to Contents | |
| The rapid reformation and
consolidation of the healthcare delivery system is well recognised.
An ageing population combined with the cost pressures of managed care means that both provider and payer enterprises are challenged to reduce costs whilst increasing services for this growing segment of the economy. Many healthcare organisations are going through mergers and re-engineering. The end state is not clear. As the industry progresses from fee-for-service to managed care to managing care, executive management is looking to information systems as a primary strategic asset to their healthcare enterprises. Directors are tasked with integrating disparate legacy systems within the diverse facilities of newly formed enterprises. In order to accomplish these tasks, healthcare organisations need both a strategic framework and current products to support interoperability.
| |
| 2.0 INFORMATION TECHNOLOGY for the ENTERPRISE Back to Contents | |
| The business mandate to
merge legacy systems with new information technology is not unique to
healthcare. Many enterprises require a means to reconcile multiple
computing models: data, desktop, server and network centric models.
Information system managers must meet today’s business challenges within
the constraints of legacy systems and promise of future information
technology. Microsoft is evolving an Enterprise Computing Roadmap to
provide its clients and independent software developers with such a
planning framework. The Enterprise Computing Roadmap is designed to
provide architecture, product capabilities and time frames using the
Microsoft Solutions Framework.
Within this context, Microsoft’s strategy to integrate desktops, servers, networks and legacy systems is ActiveX. ActiveX is the key crossplatform building block between applications and services whether on the same machine, across a network or over the Internet. ActiveX components are the standard for accessing Active Platform applications and services such as messaging, transaction processing, database, directory services, Internet Server and interfacing to legacy systems.
| |
| 3.0 A HISTORY of MICROSOFT COMPONENT TECHNOLOGY Back to Contents | |
| But what exactly is
ActiveX? Although it may seem that ActiveX is a brand new term, in fact
the technology foundation dates back to the early days of Windows. A quick
review of the history of this powerful technology can demonstrate
this.
| |
|
| |
| Microsoft Windows’ ability
to run multiple desktop applications simultaneously led to a desire to
have these applications share information in real time. This was first
accomplished in Windows though Dynamic Data Exchange (DDE). In the next
version of Windows, Microsoft decided to take it one step further by not
only allowing applications to share information, but also allowing one
application to exist within another for example, the ability to have
an Excel spreadsheet reside within a Word document. This function was
named OLE and defined the relationship between container applications and
server applications. Because the technology was designed to be generic,
software from other developers could also function as OLE containers or
servers.
When Microsoft moved OLE to the 32 bit versions of Windows, the developers realised that the technology was not necessarily restricted to the creation of compound documents. What they had created was a standard way for two applications to interact without having to be written together. Thus, the term OLE was expanded to encompass a wide range of technology geared towards the creation of software components.
| |
|
| |
| As the Internet and the
World Wide Web took centre stage in the computing arena, OLE continued to
evolve to meet new challenges. The new version of OLE needed to be small
and efficient so that it could be deployed over slow communications links.
It also needed to be able to work equally well in web applications,
desktop applications, and server applications. But the name OLE had moved
so far beyond its roots that a new term was needed to describe this new
architecture. Thus, the name ActiveX was born to encompass the Microsoft
strategy for component software.
| |
| 4.0 ActiveX TECHNOLOGY FOUNDATION Back to Contents | |
| Understanding how ActiveX
works requires an understanding of the Microsoft Component Object Model
(COM). COM is a low level binary specification, the ‘plumbing’ that makes
ActiveX work.
|
Figure one: An interface is a collection of functions, which are supported by a COM object. All interactions with a COM object are accomplished through interfaces. As shown above, all COM objects support an interface called IUnknown*. This interface allows applications, which are using the object to discover what other interfaces are supported.
|
|
| |
| COM is based on two
primary concepts: objects and interfaces. A COM object is compiled code,
which adheres to the COM binary specification. It is important to
recognise that COM objects are delivered as compiled objects rather than
source code. This means that end users can use these components without
having to understand how the object was implemented.
| |
|
| |
| One of the most
powerful aspects of COM is its location independence. This means that the
mechanics of interaction between COM objects and client applications are
generally the same no matter where they have been deployed. COM objects
can be inprocess, which means that interaction is fast and efficient.
Applications can also interact with COM objects in another process on the
same machine, called crossprocess. Finally, Distributed COM (DCOM) allows
a client to interact with a COM object across the network. This common
interaction model means that developers use a single development model and
then determine the best application configuration at deployment
time.
| |
| Figure
two: COM Interaction Model: in-process, cross-process, and
network
| |
| 5.0 ActiveX for HEALTHCARE | Back to Contents |
| ActiveX for Healthcare is
a collaborative effort between Microsoft, its users and independent
software developers to bring the underlying power of Microsoft enterprise
object technology to the healthcare industry. ActiveX for Healthcare is a
multi-level standard designed to provide interoperability between
healthcare applications and systems. When fully implemented, ActiveX for
Healthcare will allow a user to select any compliant application or
component and plug it into their system with an assurance that it will
play. All deliverables and specifications that are a result of the ActiveX
for Healthcare initiative are freely licensed to software developers and
healthcare organisations for inclusion in their products and systems.
Because of the flexibility of ActiveX, there are many possible uses of the technology in a variety of healthcare scenarios. Three uses are of special interest:
Sending healthcare messages between independent applications running on a local network or the Internet for example, passing charges between a pharmacy system and a billing system. This scenario is the focus of this white paper and the ActiveX for Healthcare initiative to date.
| |
| 6.0 ActiveX for HEALTHCARE: MESSAGING Back to Contents | |
| Today’s
healthcare enterprise, from a single doctor’s practice to an integrated
delivery network, must share data among applications from many developers
both inside and outside the organisation. Most healthcare data exchange
has been based on point-to-point custom interfaces. While functional, this
approach does not scale as the number of systems increases. The use of an
interface engine can help with the problems of managing multiple
point-to-point and proprietary interfaces, but can be expensive for small
installations and does not provide a framework for real time interaction
between distributed applications. ActiveX for Healthcare messaging
components complement high-end interface engines by providing a cost
effective, easy to use architecture for interoperability.
| |
|
|
Back to Contents |
| The application is the
client in the ActiveX for Healthcare messaging architecture, typically
written by an independent software developer or healthcare organisation.
While the client application might be an end user application running on a
workstation, it may just as easily be a non-interactive
service running on a remote machine. Client applications can be written in any ActiveX enabled language or environment. The Microsoft Visual C++ programming system, Visual Basic, Microsoft Access, Delphi, and PowerBuilder are all excellent languages for developing ActiveX for Healthcare messaging applications. In addition, ActiveX for Healthcare messaging components are accessible from the Visual Basic for Applications environment used by Microsoft Office and the ActiveX scripting environment used in Internet Explorer. The general scenario for a client application is:
Client applications can either specify the destination for a message or use a default destination specified by a system administrator.
| |
Figure three. ActiveX for Healthcare messaging architecture
| |
|
|
Back to Contents |
| The ActiveX for Healthcare
messenger is the traffic policeman, responsible for creating empty
messages for the application and routing messages to the appropriate
destination. The Messenger is a dynamic link library (DLL) written using
Microsoft’s ActiveX Template Library. To accomplish its tasks, the
messenger loads the appropriate message factory and message transports as
specified in the system configuration. The messenger does not currently
guarantee that messages will be delivered – it is up to the application to
handle failure cases.
| |
|
|
Back to Contents |
| The ActiveX for
Healthcare message factory is responsible for creating blank message
objects which are passed back to the application. Depending on which type
of message the client application requests, one or more message factories
may be loaded. The first available factory creates standard HL7 2.3
messages mapped into objects, based on the work of the HL7 Object
Brokering Technologies Special Interest Group (SIGOBT).
| |
|
| |
| The message
transport is responsible for packaging and delivering a message which has
been requested to be sent. The initial transport included in the Software
Development Kit (SDK) packages the message in a binary stream and uses
DCOM to pass it to another client application.
Other transports (e.g. using a TCP/IP socket to transmit an ASCII encoded HL7 string) can be added. This flexible architecture provides users and developers with a migration path between today’s legacy systems and interface engines and tomorrow’s networked, component based applications.
| |
| 7.0 ActiveX for HEALTHCARE COMMITTEE Back to Contents | |
| Following the
success of the Microsoft Healthcare Users Group (MS-HUG) in the US, the
Microsoft Healthcare Users Group Europe (MS-HUGe) was launched in
September 1997. The European healthcare sector is characterised by many
heterogeneous local markets, each with differing needs. The creation
MS-HUGe means that the needs and interests of European users and
developers can be better addressed.
In autumn 1996, the Microsoft Healthcare User Group in the US launched the ActiveX for Healthcare Committee. The new European group will work closely with the organisation in the US, particularly to develop and implement the standards and tools necessary to advance the use of ActiveX in Europe, which will solve the integration and interoperability challenges facing healthcare. The organisation in the US has entered into an agreement with the Andover Working Group, through which the Andover Working group provided its HL7 Enterprise Communication Framework (ECF) application programming interface (API) specification. This ensures that applications can be moved easily between ActiveX for Healthcare and ECF implementations. The goals of MS-HUGe in the ActiveX for Healthcare field are to:
| |
|
|
Back to Contents |
| Certification
is an essential part of the ActiveX for Healthcare initiative. Current
healthcare standards do not provide customers with any confidence that
developers who implement the standard will be able to interoperate. By
receiving ActiveX for Healthcare certification and a logo for an
application, developers will be able to offer their customers a higher
level of confidence. Along with providing a framework for independent
software developers and end users, the committee intends to evolve the
ActiveX for Healthcare certification in phases over time. Three phases
have been identified:
Phase 1: Implementation of API standard using the Messenger and Message Factory: The first phase will ensure that developers have implemented the ActiveX for Healthcare messaging API in their application. Certification will require that developers supply a set of supported messages which will be sent/received by the application. Phase 2: Standard for implementing standard message content: The second phase of the certification process requires that the content of messages sent by the developer applications meets the requirements specified by the appropriate message profile for their application’s messaging role. The group has entered into an agreement with the Andover Working Group to use the HL7 ECF message developer profiles to assist in resolving outstanding ambiguity in HL7 message content. Phase 3: Standard for implementing state awareness and transactions: This phase is least defined and represents a significant advance in interoperability from data exchange to transaction processing and state awareness. This phase will enable applications to use network services to conduct transactions with static and dynamic methods within a selfdescribing, distributed system.
| |
|
|
Back to Contents |
| The US
organisation released the initial deliverables of the ActiveX for
Healthcare Committee initiative to the healthcare community, at the MS-HUG
Windows on Healthcare III conference in September 1997. Based on the
Andover Working Group’s API, ActiveX for Healthcare member firms developed
a prototype messenger, HL7 2.3 Message Factory, and DCOM transport as
ActiveX in-process components or DLLs. These are available in SDK form on
a CD-ROM or from the ActiveX for Healthcare web site at MS-HUG. Selected
messages from all chapters of the HL7 standard have been incorporated into
the Message Factory. Currently the list of all destination applications is
maintained in each local host registry. The application is responsible for
data transliteration, security and transaction processing.
The next steps are to use the message profiles supplied by the Andover Working Group to assist in resolving outstanding ambiguity in HL7 message content. The group also plans to deliver a message factory to implement the object based HL7 Version 3, as well as factories and profiles for other healthcare data standards including ANSI X12, ASTM, DICOM, and EDIFACT.
| |
| 8.0 GETTING STARTED | Back to Contents |
| One of the best
things about ActiveX for Healthcare is that it is here today.
Organisations can take the first steps towards understanding and using
this new technology.
| |
|
| |
| By
incorporating the ActiveX for Healthcare messaging components into current
products for Windows NT and Windows 95, an independent software developer
has solved a tactical interfacing question and adopted a strategic
standard for interoperability. Implementing the current level facilitates
standard HL7 messaging with or without interface engines. Interfacing to
other ActiveX for Healthcare developers becomes easy through the use of
the supplied DCOM transport. Finally, ActiveX for Healthcare messaging
certification lets end users know that a developer has a plan for
migrating to a true Plug-and-Play environment.
In the longer term, developers who incorporate ActiveX for Healthcare messaging components will be able to incorporate the object based HL7 3.0 as well as additional message factories such as ANSI X12. Finally, as Microsoft rolls out its full Active Server platform, the application can readily make use of transaction processing, messaging, security, directory and Internet services. To get started, interested developers should obtain Phase 1 certification through MS-HUG USA and receive the Microsoft ActiveX for Healthcare Messaging logo. Developers are further encouraged to participate in AHC to advance the standard effort.
| |
|
|
Back to Contents |
| The ActiveX for
Healthcare initiative provides the user with both a strategic framework
for future interoperability and current interfacing capabilities. ActiveX
for Healthcare Messaging components are based on both healthcare and
information technology standards. While based on HL7, ActiveX for
Healthcare can also incorporate healthcare data standards. Thus, for the
IT Director that needs to make application decisions that will work in
today’s legacy computing environment and be compatible with future
distributed computing, the ActiveX for Healthcare messaging certification
becomes a must on developer selection lists.
| |
| 9.0 REFERENCES | Back to Contents |
| Information
about ActiveX for Healthcare, software and documentation for developers,
and how to join the ActiveX for Healthcare initiative can be found at the
ActiveX for Healthcare web site, http://www.mshug.org/activex/
If you are not yet a member of the Microsoft Healthcare Users Group Europe, you can visit http://www.mshug-euro.org/ or call Sarah Owens, Microsoft Healthcare Users Group Europe on +44 (0)171 453 2288 Information about Hewlett Packard’s Andover Working Group can be found at http://www.hp.com/go/medical/ Information about Health Level-7 and the Special Interest Group on Object Brokering Technologies (SIGOBT) is located at http://www.mcis.duke.edu/standards/HL7/hl7.htm Learn about Microsoft’s efforts in the healthcare industry from the Healthcare Industry web site http://www.microsoft.com/industry/health/ Alternatively, visit the Microsoft Europe Healthcare Industry web site http://www.microsoft.com/europe/industry/healthcare/ An excellent introduction to ActiveX is David Chappel’s Understanding ActiveX and OLE, available through Microsoft Press at http://www.microsoft.com/mspress / | |
|
| |
| Back to Contents | |
|
© 1998 Microsoft Europe and Microsoft Healthcare Users Group Europe. All rights reserved. This white paper is for informational purposes only. MICROSFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, ActiveX, MS, Visual basic, Visual C++, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. | |
 |
Copyright 2002 © MS-HUGE All
rights reserved Suggestions: mailto:webmaster@ramit.be?subject=MSHUGE website or Martine Vannevel |
Nov 26 1998 home |
