| Special Features Of An EMR |
|
 |
|
| |
|
|
|
| Implementing an electronic medical record (EMR) is a major initiative that should be undertaken only after a thoughtful analysis of the costs and benefits involved. |
| read more |
|
|
|
| ADA for exchanging data processing standards to the dental services of the health care industry... |
| read more |
|
|
| Barack Obama: In his Plan for a Healthy America, Obama calls for lowering costs through investment in electronic health information technology systems, acknowledging... |
| read more |
| |
| |
|
 |
| |
|
1.
DICOM
2. HL7
1.
DICOM
The purpose of this document is to provide a summary
of the current activities and future directions
of the Digital Imaging and
Communications in Medicine (DICOM) standard.
The content of the document is largely based on
information submitted by individual working group
chairs. WG10 will update this document on an annual
basis and submit it for review and approval by
the DICOM Committee at the committee’s annual
RSNA meeting.
A Brief
Background of the DICOM Standard
The introduction of digital medical image sources
in the 1970’s and the use of computers in
processing these images after their acquisition
led the American College of
Radiology (ACR) and the National Electrical Manufacturers
Association (NEMA) to form a joint committee
in order to create a standard method for the transmission
of medical images and their associated information.
This committee, formed in 1983, published in 1985
the ACR-NEMA Standards Publication No. 300-1985.
Prior to this, most devices stored images in a
proprietary format and transferred files of these
proprietary formats over a network or on removable
media in order to perform image communication.
While the initial versions of the ACR-NEMA effort
(version 2.0 was published in 1988) created standardized
terminology, an information structure, and unsanctioned
file encoding, most of the promise of a standard
method of communicating digital image information
was not realized until the release of version
3.0 of the standard in 1993. The release of version
3.0 saw a name change, to Digital Imaging and
Communications in Medicine (DICOM), and numerous
enhancements that delivered on the promise of
standardized communications.
The DICOM standard now specified a network protocol
utilizing TCP/IP, defined the operation of Service
Classes beyond the simple transfer of data, and
created a mechanism for uniquely identifying Information
Objects as they are acted upon across the network.
DICOM was also structured as a multi-part document
in order to facilitate extension of the Standard.
Additionally, DICOM defined Information Objects
not only for images but also for patients, studies,
reports, and other data groupings. With the enhancements
made in DICOM (Version 3.0), the Standard was
now ready to deliver on its promise not only of
permitting the transfer of medical images in a
multi-vendor environment, but also facilitating
the development and expansion of picture archiving
and communication systems (PACS) and interfacing
with medical information systems.
Scope
of DICOM
The DICOM Standards Committee exists to create
and maintain international standards for communication
of biomedical diagnostic and therapeutic information
in disciplines that use digital images and associated
data. The goals of DICOM are to achieve compatibility
and to improve workflow efficiency between imaging
systems and other information systems in healthcare
environments worldwide. DICOM is a cooperative
standard. Therefore, connectivity works because
vendors cooperate in testing via scheduled public
demonstration, over the Internet, and during private
test sessions. Every major diagnostic medical
imaging vendor in the world has incorporated the
standard into their product design and most are
actively participating in the enhancement of the
standard. Most of the professional societies throughout
the world have supported and are participating
in the enhancement of the standard as well.
DICOM is used or will soon be used by virtually
every medical profession that utilizes images
within the healthcare industry. These include
cardiology, dentistry, endoscopy, mammography,
ophthalmology, orthopedics, pathology, pediatrics,
radiation therapy, radiology, surgery, etc. DICOM
is even used in veterinary medical imaging applications. |
 |
Technology
Overview
The DICOM Standard addresses multiple levels of
the ISO OSI network model and provides support
for the exchange of information on interchange
media. DICOM currently defines an upper layer
protocol (ULP) that is used over TCP/IP (independent
of the physical network), messages, services,
information objects and an association negotiation
mechanism. These definitions ensure that any two
implementations of a compatible set of services
and information objects can effectively communicate.
Independence from the underlying network technology
allows DICOM to be deployed in many functional
areas of application, including but not limited
to communication within a single site (often using
various forms of Ethernet), between sites over
leased lines or Virtual Private
Networks (VPNs), within a metropolitan
area (often using ATM), across dial-up or other
remote access connections (such as by modem, ISDN
or DSL), and via satellite (with optimized protocol
stacks to account for increased latency). |
| |
| At
the application layer, the services and information
objects address five primary areas of functionality: |
- Transmission and persistence of complete
objects (such as images, waveforms and documents),
- Query and retrieval of such objects,
- Performance of specific actions (such as
printing images on film),
- Workflow management (support of work lists
and status information) and
- Quality and consistency of image appearance
(both for display and print).
|
DICOM
does not define architecture for an entire system;
nor does it specify functional requirements, beyond
the behavior defined for specific services. For
example, storage of image objects is defined only
in terms of what information must be transmitted
and retained, not how images are displayed or
annotated. DICOM can be considered as a standard
for communication across the “boundaries”
between heterogeneous or disparate applications,
devices and systems.
The services and objects that are defined in DICOM
are designed to address specific, real-world applications
(such as the performance of an imaging study on
an acquisition device). As such, DICOM is not
a general-purpose tool for distributed object
management. In general, information is transferred
“in bulk” according to a “document”
paradigm.
By contrast, general-purpose standards for distributed
object or database management generally provide
lower level, more atomic access to individual
attributes. Though the DICOM standard does provide
the so-called “normalized” services
for patient and study management, these have not
proven popular, and the “composite”,
document-oriented, services have prevailed. This
is mostly likely a consequence of the natural
division of functionality between different vendors,
devices and applications. For example, the ability
to “set” or “change” a
patient’s name is generally implemented
in a proprietary and centralized manner. To safely
distribute responsibility for such a change across
boundaries between different applications requires
more underlying support than DICOM currently possesses
(such as support for transactions and two-phase
commitment).
At the present time, the pressing needs in DICOM
(as indicated by the priorities of the various
working groups) are to address issues relating
to security, performance, new modality technology,
and workflow management. These needs are being
successfully addressed using the conventional
“underlying” DICOM technology. Where
there are interfaces to standards based on other
technologies (such as HL7 V2.x and 3), the focus
for harmonization is on a shared “information
model”. It may be the case that the nature
of the underlying technology needs to be revisited
in the future, whether it is to make use of more
sophisticated off-the-shelf distributed object
management tools such as CORBA, or less sophisticated
encoding tools such as XML. However, the current
priority is to address improvements in functionality
to better meet the needs of the end-user, rather
than to adopt an alternative technology for the
sake of it. This priority is continually reinforced
by a desire to remain compatible with the installed
base of equipment.
When specific new technology is required, such
as in support of new features such as security
and compression, the strategy is to adopt proven
international, industry or de facto standards.
Accordingly, network confidentiality and peer
authentication in DICOM are provided by the use
of either TLS (an Internet standard) or ISCL (an
ISO-based standard). Similarly, rather then develop
medical-image-specific compression schemes, DICOM
adopts standards developed by ISO/IEC JTC 1/SC
29/WG 1 such as JPEG and JPEG 2000. For interchange
media, standard file systems compatible with conventional
software (such as ISO 9660 and UDF) are used. |
|
DICOM’s
Relationship to Other Standards
Throughout the development of DICOM, much attention
was devoted to establishing working relationships
with other related standard initiatives throughout
the world. The initial version of the standard
leveraged prior work by ASTM. The Internet protocol
TCP/IP was adopted in 1993. In the nineties, solid
cooperation with CEN, the European Committee for
Standardization, resulted in a number of jointly
developed supplements. In parallel, the convergence
of a Japanese interchange media format (IS&C)
with DICOM required much joint work where JIRA,
the Japan Industries Association of Radiological
Systems played a major role. In the USA, DICOM
participated in the early coordination efforts
for healthcare standards with the ANSI-HISBB from
which DICOM adopted a harmonized patient name
structure, and started progressively to define
links with HL7. This cooperation has now entered
in a very active phase with the creation, in 1999,
of a joint DICOM-HL7 working group. Finally, it
was a logical step for DICOM to establish a Type
A liaison with the ISO Technical Committee 215
at its creation in 1999. ISO TC 215 has decided
not to create an imaging working group, but to
rely on DICOM for bio-medical imaging standards.
DICOM is also focusing its attention to the evolution
of standards linked to the Internet. DICOM strategy
is to integrate Internet Recommendations as soon
as they are stable and largely disseminated in
consumer commercial products. In this evolution,
much care is taken to ensure that the consistency
of the DICOM standard is maintained with its large
installed base. DICOM already uses standard healthcare
enterprise intranets and soon the e-mail exchange
of DICOM objects (Standard MIME type) should be
possible. It is clear that the use of DICOM objects
and services in commonly used information technology
applications will grow in the future.
2. HEALTH LEVEL 7 (HL7)
Health Level Seven
Health Level Seven is one of several American
National Standards Institute (ANSI) - accredited
Standards Developing Organizations (SDOs) operating
in the healthcare arena. Most SDOs produce standards
(sometimes called specifications or protocols)
for a particular healthcare domain such as pharmacy,
medical devices, imaging or insurance (claims
processing) transactions. Health Level Seven’s
domain is clinical and administrative data.
Headquartered in Ann Arbor, MI, Health Level Seven
is like most of the other SDOs in that it is a
not-for-profit volunteer organization. Its members--
providers, vendors, payers, consultants, government
groups and others who have an interest in the
development and advancement of clinical and administrative
standards for healthcare - develop the standards.
Like all ANSI-accredited SDOs, Health Level Seven
adheres to a strict and well-defined set of operating
procedures that ensures consensus, openness and
balance of interest. A frequent misconception
about Health Level Seven (and presumably about
the other SDOs) is that it develops software.
In reality, Health Level Seven develops specifications;
the most widely used being a messaging standard
that enables disparate healthcare applications
to exchange keys sets of clinical and administrative
data.
Members of Health Level Seven are known collectively
as the Working Group, which is organized into
technical committees and special interest groups.
The technical committees are directly responsible
for the content of the Standards. Special interest
groups serve as a test bed for exploring new areas
that may need coverage in HL7’s published
standards.
HL7's Vision
To create the best and most widely used standards
in healthcare.
HL7's
Mission
HL7 provides standards for interoperability that
improve care delivery, optimize workflow, reduce
ambiguity and enhance knowledge transfer among
all of our stakeholders, including healthcare
providers, government agencies, the vendor community,
fellow SDOs and patients. In all of our processes
we exhibit timeliness, scientific rigor and technical
expertise without compromising transparency, accountability,
practicality, or our willingness to put the needs
of our stakeholders first.
What
Does the Name HL7 Mean
"Level
seven" refers to the highest level
of the International Organization for Standardization
(ISO) communications model for Open Systems Interconnection
(OSI) - the application level. The application
level addresses definition of the data to be exchanged,
the timing of the interchange, and the communication
of certain errors to the application. The seventh
level supports such functions as security checks,
participant identification, availability checks,
exchange mechanism negotiations and, most importantly,
data exchange structuring. |
|
| HL7's
Strategies: |
- Develop coherent, extendible standards that
permit structured, encoded health care information
of the type required to support patient care,
to be exchanged between computer applications
while preserving meaning.
- Develop a formal methodology to support
the creation of HL7 standards from the HL7
Reference Information Model (RIM).
- Educate the healthcare industry, policy
makers, and the general public concerning
the benefits of healthcare information standardization
generally and HL7 standards specifically.
- Promote the use of HL7 standards world-wide
through the creation of HL7 International
Affiliate organizations, which participate
in developing HL7 standards and which localize
HL7 standards as required.
- Stimulate, encourage and facilitate domain
experts from healthcare industry stakeholder
organizations to participate in HL7 to develop
healthcare information standards in their
area of expertise.
- Collaborate with other standards development
organizations and national and international
sanctioning bodies (e.g.ANSI and ISO), in
both the healthcare and information infrastructure
domains to promote the use of supportive and
compatible standards.
- Collaborate with healthcare information
technology users to ensure that HL7 standards
meet real-world requirements, and that appropriate
standards development efforts are initiated
by HL7 to meet emergent requirements.
|
Why
HL7
There are several health care standards development
efforts currently underway throughout the world.
Why then, embrace HL7? HL7 is singular as it focuses
on the interface requirements of the entire health
care organization, while most other efforts focus
on the requirements of a particular department.
Moreover, on an ongoing basis, HL7 develops a
set of protocols on the fastest possible track
that is both responsive and responsible to its
members. The group addresses the unique requirements
of already installed hospital and departmental
systems, some of which use mature technologies.
While HL7 focuses on addressing immediate needs,
the group continues to dedicate its efforts to
ensuring concurrence with other United States
and International standards development activities.
Argentina, Australia, Canada, China, Czech Republic,
Finland, Germany, India, Japan, Korea, Lithuania,
The Netherlands, New Zealand, Southern Africa,
Switzerland, Taiwan, Turkey and the United Kingdom
are part of HL7 initiatives. Moreover, HL7 is
an American National Standards Institute (ANSI)
approved Standards Developing Organization.
(SDO). HL7 strives to identify and support the
diverse requirements of each of its membership
constituencies: Users, Vendors, and Consultants.
Cognizant of their needs, requirements, priorities
and interests, HL7 supports all groups as they
make important contributions to the quality of
the organization. The committee structure, balanced
balloting procedures and open membership policies
ensure that all requirements are addressed uniformly
and equitably with quality and consistency.
How is HL7 Organized.
The organization is managed by a Board of Directors,
which is comprised of eight elected positions
and three appointed positions. The organization
is comprised of Technical Committees and Special
Interest Groups that are responsible for defining
the HL7 standard protocol. Each Technical Committee
and Special Interest group is chaired by two or
more co-chairs. Collectively, the co-chairs comprise
the Technical Steering Committee, which votes
on issues related to the standard. Votes of the
Technical Steering Committee are passed as recommendations
to the Board of Directors, who make the final
decision. HL7 members are encouraged to participate
in all of these committees.
Mission
/ Charter
Mission
The goal of the Electronic Health Record (EHR)
Technical Committee is to support the HL7 mission
of designing standards to support the sharing
of electronic health records. It will accomplish
this goal through contributing to the creation
and promotion of appropriate and necessary standards
including the definition of a high-level architecture
to support the interoperability requirements among
EHR Systems.
Charter
Work Products and Contributions to HL7 Processes |
- Provide a forum for discussion of what standards
and definitions are necessary to obtain interoperability
among Electronic Health Record Systems across
disparate providers. Different solutions will
be examined and certain solutions will be
advanced as standards.
- Create a functional model for EHR Systems
in a variety of health care settings.
- Define requirements for the interoperable
exchange of Electronic Health Records or components
thereof.
- Create use cases to help define the requirements
for EHR interoperability
- Coordinated/shared care of patients across
disparate healthcare providers
- Query for records or components of an EHR
- Use the HDF methodology to define EHR requirements,
including privacy and security requirements,
as well as requirements for EHR transactions.
- This document recognizes the unique characteristics
of the EHR TC in that required messages will
fall within the scope of other TCs. Therefore,
the EHR TC will collaborate with other appropriate
TCs to produce the appropriate standards,
including messages, to meet EHR requirements.
|
|
|
| |
|
| |
|