Health Information Standard HL7

1
Health Information StandardHL7

• Feipei Lai
• National Taiwan University

2
What is HL7?

• http//www.hl7.org/
• 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.

3
HL7

• HL7s domain is clinical and administrative data.
• Our mission is to "To provide standards for the
  exchange, management and integration of data that
  support clinical patient care and the management,
  delivery and evaluation of healthcare services.
• Specifically, to create flexible, cost effective
  approaches, standards, guidelines, methodologies,
  and related services for interoperability between
  healthcare information systems."

4
HL7

• 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.

5
HL7

• 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.

6
HL7

• Members of HL7 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
  HL7s published standards.

7
What Does the Name HL7 Mean?

• "Level Seven" refers to the highest level of the
  International Standards Organization's (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.

8
Why 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.

9
HL7

• 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.

10
HL7 New and Ongoing Initiatives

• HIPAA
• HL7s initial involvement in the HIPAA
  legislation began in 1996 with the formation of
  the Claims Attachments special interest group.
• The Attachment Special Interest Group was formed
  to standardize the supplemental information
  needed to support health care insurance, and
  other e-commerce transactions.

11
HIPAA

• The initial deliverable of this group was six
  recommended Claims Attachments for the Notice of
  Proposed Rule Making (NPRM) process.
• Future attachment projects include, but are not
  limited to, Home Health, Skilled Nursing
  Facility, Durable Medical Equipment (DME), End
  Stage Renal Disease (ESRD), and Pre-Authorization
  and Referrals.

12
HIPAA

• Attachment special interest group is tasked with
  assisting in the implementation of the
  Administrative Simplification provisions of HIPAA
  mandates, providing on-going support, and to
  represent HL7 in the HIPAA Designated Standards
  Maintenance Organization (DSMO) efforts.

13
HIPAA

• Its purpose is to encourage the use of HL7 for
  uniform implementation of this supplemental
  information.
• This SIG coordinates industry input to produce
  and maintain guides for HL7 messages that can
  stand alone or be embedded within ASC X12N
  transactions.

14
ASC X12

• is the U.S. standards body for the cross-industry
  development, maintenance, and publication of
  electronic data exchange standards, based on, but
  not limited to X12 EDI, XML, and UN/EDIFACT
  formats.
• As the preferred standards body for defining
  requirements of electronic business document
  content, ASC X12 also serves as a key player in
  international forums by contributing to the
  universal core component work and message design
  architecture.

15
HIPAA

• The Health Insurance Portability and
  Accountability Act of 1996 requires all health
  plans, health care clearinghouses, and health
  care providers who conduct electronic
  financial/administrative transactions (e.g.,
  electronic billing) to comply with national
  patient privacy standards, which contain
  safeguards to protect the security and
  confidentiality of patient information.

16
HL7

• The Reference Information Model (RIM)
• RIM is the cornerstone of the HL7 Version 3
  development process.
• An object model created as part of the Version 3
  methodology, the RIM is a large pictorial
  representation of the clinical data (domains) and
  identifies the life cycle of events that a
  message or groups of related messages will carry.

17
HL7 RIM

• It is a shared model between all the domains and
  as such is the model from which all domains
  create their messages.
• Explicitly representing the connections that
  exist between the information carried in the
  fields of HL7 messages, the RIM is essential to
  our ongoing mission of increasing precision and
  reducing implementation costs.

18
Version 3 Meta-model for RIM
19
HL7 Templates

• An HL7 template is a data structure, based on the
  HL7 Reference Information Model, and which
  expresses the data content needed in a specific
  clinical or administrative context.
• They are prescribed patterns by which multiple
  OBX segments may be combined to describe
  selected, gross observations.

20
HL7 Templates

• Some observations may be quite simple, such as
  the blood pressure concept in healthcare, which
  involves a set of expected observations (i.e.,
  systolic, diastolic, patient position, method,
  etc.)
• Other more elaborate diagnostic procedures may
  involve hundreds of related pieces of
  information, including anatomy, orientation,
  sequences of measurements, etc.

21
HL7 Templates

• Templates provide a means of coupling the
  multiple OBX segments needed to send the
  observation with separately encapsulated rules
  for combining/validating them for the particular
  observation.
• Based on user need and preference, the template
  offers the user the advantage of defining the
  collection of OBX segments needed and the
  corresponding set of validation rules once, and
  once defined, the structure can be used again and
  again. Since they are based on a specific user's
  needs/requirements, Templates can be "plug and
  play" at a given user site.

22
HL7

• Templates Special Interest Group will create
  normative standards for the definition of HL7
  templates. These standards will provide that an
  HL7 template be composed of data structures drawn
  from the HL7 RIM, that make use of HL7 vocabulary
  domains.
• The group will also define the procedures for
  administering a meta-data repository to serve as
  the home for templates defined by HL7 bodies, HL7
  members, and other parties, and will develop
  procedures and educational material to guide
  interested parties in the development of HL7
  templates

23
HL7 Vocabulary

• while data can be exchanged between systems, its
  usefulness is compromised unless there is a
  shared, well defined, and unambiguous knowledge
  of the meaning of the data transferred.
• Since much of the data being transferred is
  coded, either by HL7 or other organizations, HL7
  began a focused effort via the formation of the
  Vocabulary Technical Committee to organize and
  maintain vocabulary terms used in its messages.

24
HL7 Vocabulary

• This group is working to provide an organization
  and repository for maintaining a coded vocabulary
  that, when used in conjunction with HL7 and
  related standards, will enable the exchange of
  clinical data and information so that sending and
  receiving systems have a shared, well defined,
  and unambiguous knowledge of the meaning of the
  data transferred.

25
HL7 Vocabulary

• The purpose of the exchange of clinical data
  includes, but is not limited to provision of
  clinical care, support of clinical and
  administrative research, execution of automated
  transaction oriented decision logic (medical
  logic modules), support of outcomes research,
  support of clinical trials, and to support data
  reporting to government and other authorized
  third parties.

26
HL7 Vocabulary

• Some of the groups that to work closely with
  include
• standards development organizations,
• creators and maintainers of vocabularies,
• government agencies and regulatory bodies,
• clinical professional specialty groups,
• vocabulary content providers,
• and vocabulary tool vendors.

27
HL7 XML

• HL7 has been actively working with XML technology
  since the formation of the SGML/XML Special
  Interest Group in September of 1996. Since that
  time, the SGML/XML group has evolved into two
  separate groups
• the XML Special Interest Group - which supports
  the HL7 mission through recommendations on use of
  Extensible Markup Language (XML) standards for
  all of HL7's platform- and vendor-independent
  healthcare specifications.

28
HL7 XML

• the Structured Documents Technical Committee -
  which support the HL7 mission through development
  of structured document standards for healthcare.
• In 1999, HL7 endorsed a recommendation for using
  XML as an alternative syntax for HL7 V2.3.1
  messages.

29
HL7 XML

• In September 2000, the HL7 membership ratified
  Version 1 of the Clinical Document Architecture,
  which defines an XML architecture for exchange of
  clinical documents.
• The encoding is based on XML DTDs included in the
  specification and its semantics are defined using
  the HL7 RIM (Reference Information Model) and HL7
  registered coded vocabularies.
• The initial release of Version 3, slated for
  publication in Dec. 2001, uses only XML encoding.

30
HL7 Specifications

• The Messaging Standard
• Version 3.0
• Version represents a significant departure from
  "business as usual" for HL7. Offering lots of
  optionality and thus flexibility, the V2.x series
  of messages were widely implemented and very
  successful. These messages evolved over several
  years using a "bottom-up" approach that has
  addressed individual needs through an evolving
  ad-hoc methodology.

31
HL7 Specifications

• HL7's success is also largely attributable to its
  flexibility. It contains many optional data
  elements and data segments, making it adaptable
  to almost any site.
• While providing great flexibility, its
  optionality also makes it impossible to have
  reliable conformance tests of any vendor's
  implementation and also forces implementers to
  spend more time analyzing and planning their
  interfaces to ensure that both parties are using
  the same optional features.

32
HL7 Specifications

• Version 3 addresses these and other issues by
  using a well-defined methodology based on a
  reference information (i.e., data) model.
• Using rigorous analytic and message building
  techniques and incorporating more trigger events
  and message formats with very little optionality,
  HL7's primary goal for Version 3 is to offer a
  standard that is definite and testable, and
  provide the ability to certify vendors'
  conformance.

33
HL7 Specifications

• Version 3 uses an object-oriented development
  methodology and a Reference Information Model
  (RIM) to create messages.
• The RIM is an essential part of the HL7 Version 3
  development methodology, as it provides an
  explicit representation of the semantic and
  lexical connections that exist between the
  information carried in the fields of HL7
  messages.

34
HL7 Specifications

• Version 2.5
• Approved as an ANSI Standard June 26, 2003.
• The HL7 Version 2 Messaging Standard
  Application Protocol for Electronic Data Exchange
  in Healthcare Environments is considered to be
  the workhorse of data exchange in healthcare and
  is the most widely implemented standard for
  healthcare information in the world.
• HL7 Version 2.5 introduces a number of new
  events, segments and messages, as well as a
  significantly expanded chapter on Control.

35
HL7 Specifications

• Modifications from Version 2.4 include
• Improved documentation of the data types
• The definition of a message profile methodology
• Better support for imaging (IHE) by means of a
  new segment and a new order message
• Support for orders related to blood products
• A new message that supports diagnoses/procedure
  messages in 'update' mode

36
HL7 Specifications

• Version 2.4
• Approved as an ANSI Standard Oct. 6, 2000.
• HL7 v.24 introduces Conformance Query profiles in
  chapters 5, and adds messages for laboratory
  automation, application management and personnel
  management.
• Additionally, a new event, specific to OPPS and
  APC requirements was added. This event, Transmit
  Ambulatory Payment, includes two new segments,
  the Grouping/Reimbursement Visit Segment and the
  Grouping Reimbursement Procedure Segment.

37
HL7 Specifications

• 1 Introduction Overview of HL7.
• 2 - Control Message Definitions, Interchange
  Protocols.
• 3 - Patient Administration Admit, Discharge,
  Transfer, and Demographics.
• 4 - Order Entry Orders for Clinical Services and
  Observations, Pharmacy, Dietary, and Supplies.5
  - Query Rules applying to queries and to their
  responses.
• 6 - Financial Management Patient Accounting and
  Charges.
• 7 - Observation Reporting Observation Report
  Messages.
• 8 - Master Files Health Care Application Master
  Files.
• 9 - Medical Records/Information Management
  Document Management Services and Resources.

38
HL7 Specifications

• 10 - Scheduling Appointment Scheduling and
  Resources.
• 11 - Patient Referral Primary Care Referral
  Messages.
• 12 - Patient Care Problem-Oriented Records.
• 13 - Laboratory Automation Equipment status,
  specimen status, equipment inventory, equipment
  comment, equipment response, equipment
  notification, equipment test code settings,
  equipment logs/service.
• 14 - Application Management Application
  control-level requests, transmission of
  application management information.
• 15 - Personnel Management Professional
  affiliations, educational details, language
  detail, practitioner organization unit,
  practitioner detail, staff identification.

39
HL7 Specifications

• Appendix A- Data Definition Tables All HL7 and
  User-defined tables and their values.
• Appendix B- Lower Layer Protocols Protocols for
  lower layer of OSI model.
• Appendix C- BNF Message Descriptions BNF
  representations of abstract message definitions
  at the segment level.
• Appendix D-Glossary Glossary of terms

40
HL7 Specifications

• Version 2.3.1
• Approved as an ANSI Standard April 14, 1999.
• HL7 V.2.3.1 includes an updated TQ
  (timing/quantity) data type to manage order
  occurrences, updates to the OBR segments and ORU
  message to facilitate public health surveillance
  reporting, updates to tables, segments and data
  types to accommodate international paradigms for
  reporting names and pharmacy orders, and the
  addition of a new field to the ORC segment to
  satisfy the HCFA Medical Necessity requirements
  for outpatient services, and an update to the FT
  segment to satisfy federal requirements for Level
  2 Modifiers.

41
HL7 Specifications

• Version 2.3
• Approved as an ANSI Standard April 14, 1999.
• includes an updated TQ (timing/quantity) data
  type to manage order occurrences, updates to the
  OBR segments and ORU message to facilitate public
  health surveillance reporting, updates to tables,
  segments and data types to accommodate
  international paradigms for reporting names and
  pharmacy orders, and the addition of a new field
  to the ORC segment to satisfy the HCFA Medical
  Necessity requirements for outpatient services,
  and an update to the FT segment to satisfy
  federal requirements for Level 2 Modifiers.

42
HL7 Specifications

• introduces document management messages, messages
  for appointment servicing and resource
  scheduling, messages for patient referrals and
  messages to track patient goals.

43
Arden Syntax for Medical Logic Systems

• This specification covers the sharing of
  computerized health knowledge bases among
  personnel, information systems, and institutions.
• The scope has been limited to those knowledge
  bases that can be represented as a set of
  discrete modules.
• Each module, referred to as a Medical Logic
  Module (MLM), contains sufficient knowledge to
  make a single decision. Contraindication alerts,
  management suggestions, data interpretations,
  treatment protocols, and diagnosis scores are
  examples of the health knowledge that can be
  represented using MLMs.

44
MLM

• Each MLM also contains management information to
  help maintain a knowledge base of MLMs and links
  to other sources of knowledge.
• Health personnel can create MLMs directly using
  this format, and the resulting MLMs can be used
  directly by an information system that conforms
  to this specification.

45
The Clinical Document Architecture

• Approved as an ANSI Standard Nov. 2000.
• The CDA, which was until recently known as the
  Patient Record Architecture (PRA), provides an
  exchange model for clinical documents (such as
  discharge summaries and progress notes)and
  brings the healthcare industry closer to the
  realization of an electronic medical record.

46
The Clinical Document Architecture

• By leveraging the use of XML, the HL7 Reference
  Information Model (RIM) and coded vocabularies,
  the CDA makes documents both machine-readableso
  they are easily parsed and processed
  electronicallyand human-readableso they can be
  easily retrieved and used by the people who need
  them.
• CDA documents can be displayed using XML-aware
  Web browsers or wireless applications such as
  cell phones.

47
The Clinical Context Management Specification
(Clinical Context Object Workgroup CCOW)

• Version 1.3 introduces the following
  enhancements
• Definition for an annotation agent (a component
  that is allowed to add data to the clinical
  context)
• Definition for a user's digital certificate
  subject (which is the first annotation subject)
• Definition of the observation subject (which
  identifies a real-world clinical observation)

48
HL7 Specifications

• Version 1.2
• Approved as an ANSI Standard Sep. 21, 2000
• Version 1.2 introduced the following
  enhancements
• Definition for an annotation agent (a component
  that is allowed to add data to the clinical
  context)
• Definition for a user's digital certificate
  subject (which is the first annotation subject)
• Definition of the observation subject (which
  identifies a real-world clinical observation)

49
HL7 Specifications

• Version 1.1
• Approved as an ANSI Standard March 15, 2000
• Version 1.1 introduced the following
  enhancements
• Definition an Encounter subject
• Support for defining custom subjects
• Addition of BNF notation for describing syntax of
  the various strings used throughout the
  specification
• Details for supporting ActiveX implementations
  using DCOM and Windows Terminal Server.

50

• COM Component Object Model
• DCOM Distributed COM

51
HL7 Specifications

• Version 1.0
• Approved as an ANSI Standard July 26, 1999
• This was the first version of the Clinical
  Context Management Specification that was ballot
  by HL7.

52
HL7 Version 1.0

• Context Management ("CCOW") Specification
  Technology- and Subject-Independent Component
  Architecture Specifies the Health Level Seven
  Context Management Architecture (CMA).
• This architecture enables multiple applications
  to be automatically coordinated and synchronized
  in clinically meaningful ways at the
  point-of-use.
• The architecture specified in this document
  establishes the basis for bringing
  interoperability among healthcare applications to
  the point-of-use, such as the clinical desktop.

53
HL7 Version 1.0

• Context Management ("CCOW") Specification Subject
  Data Definitions Patient Subject Specifies the
  standard context data items that are available
  for applications to use in setting and accessing
  the common clinical context.

54
HL7 Version 1.0

• Context Management ("CCOW") Specification, Data
  Definition User Subject Specifies the standard
  context data items that are available for
  applications to use in setting and accessing the
  common clinical context.

55
HL7 Version 1.0

• HL7 Standard Context Management ("CCOW")
  Specification Component Technology Mapping
  ActiveX Specifies the details needed to develop
  Microsoft ActiveX implementations of applications
  and components that conform to the HL7 Context
  Management Architecture (CMA). Using this
  specification, the resulting applications and
  service components will be able to communicate
  with each other per the CMA even if they were
  independently developed.

56
HL7 Version 1.0

• Context Management Specification, User Interface
  Microsoft Window, OS. Specifies the user
  interface when using the common clinical context
  component as specified by CCOW.

57
Trigger events

• The standard is written from the assumption that
  an event in the real world of healthcare creates
  the need for data to flow among systems.
• The real-world event is called the trigger event.
• E.g. the trigger event a patient is admitted may
  cause the need for data about the patient to be
  sent to a number of other systems.

58
Acknowledgements original mode

• When the unsolicited update is sent from one
  system to another, this acknowledge mode
  specifies that it be acknowledged at the
  application level.
• The scope of HL7 is restricted to the
  specification of messages between application
  systems, and the events triggering them.

59
Acknowledgements enhanced mode

• Accept acknowledge the receiving message commits
  the message to safe storage
• and application acknowledge after message has
  been processed by the receiving systems, an
  application acknowledge may be used to return the
  resultant status to the sending system.

60
Communication environment

• HL7 defines the messages as they are exchanged
  among application entities and the procedure used
  to exchange them.
• It is primarily concerned with the data content
  and interrelationship of messages and with
  communicating certain application-level error
  conditions.
• No limits on the maximum size of HL7 messages.

61
Message framework

• Messages
• Segments and segment groups
• Fields
• Message delimiters

62
Messages

• A message is the atomic unit of data transferred
  between systems.
• It is comprised of a group of segments in a
  defined sequence.
• Message type (3 characters) defines its purpose.
• E.g. ADT message type is used to transmit
  portions of a patients Patient Administration
  (ADT) data from one system to another.
• All message types and trigger event codes
  beginning with the letter Z are reserved for
  locally defined messages.

63
Segments and segment group

• A segment is a logical grouping of data fields.
• Segments of a message may be required or
  optional.
• Each segment is given a name.
• E.g. ADT message may contain the following
  segments Message Header (MSH), Event Type (EVN),
  Patient ID (PID), and Patient Visit (PVI).

64
Segments and segment group

• Each segment is identified by a unique
  three-character code know as the Segment ID.
• All segment ID codes beginning with the letter Z
  are reserved for locally defined segments.
• Two or more segments may be organized as a
  logical unit called a segment group.
• A segment is assigned a name that represents a
  permanent identifier that may not be changed.

65
Fields

• A field is a string of characters.
• Sending the null value, which is transmitted as
  two double quote marks (). Is different from
  omitting an optional data field.
• If no value is sent, the old value should remain
  unchanged. If the null value is sent, the old
  value should be changed to null.

66
Fields position

• Position (sequence within the segment)
• Ordinal position of the data field within the
  segment. This number is used to refer to the data
  field in the text comments that follow the
  segment definition table.
• In the segment attribute tables this information
  is provided in the column labeled SEQ.

67
Fields Maximum length

• In the segment attribute tables this information
  is in a column labeled LEN.
• If the maximum length cannot be definitely
  expressed because the data type for the field is
  variable, the symbolic number 99999 should be
  displayed.

68
Fields data type

• The basic building block used to construct or
  restrict the contents of a data field.
• In the segment attribute tables this information
  is provided in the column labeled DT.
• If the data type of the field is variable, the
  notation varies will be displayed.

69
Fields optionality

• Whether the field is required, optional, or
  conditional in a segment.
• In the segment attribute tables this information
  is provided in the column labeled OPT.
• R required
• O optional
• C conditional on the trigger event or on some
  other fields.
• X not used with this trigger event
• B left in for backward compatibility with
  previous version of HL7.
• W withdrawn

70
Fields repetition

• Whether the field may repeat.
• In the segment attribute tables this information
  is provided in the column labeled RP/.
• N or blank no repetition
• Y the field may repeat an indefinite or
  site-determined number of times
• (integer) the field may repeat up to the number
  of times specified by the integer

71
Fields table

• The table attribute of the data field definition
  specifies the HL7 identifier for a set of coded
  values.
• In the segment attribute tables, the table
  identifier is provided in the column labeled
  TBL.
• HL7 tables, external tables, local tables

72
HL7 Tables

• An HL7 table is a set of values defined and
  published by HL7.

73
External Tables

• An external table is a set of coded values
  defined and published by another standards
  organization.
• E.g. the coding of clinical observations using
  LOINC codes

74
Local Tables

• A local table is a table with a non-HL7 assigned
  table identifier and which contains a set of
  locally or site defined values.

75
Fields ID number

• A small integer that uniquely identifies the data
  item throughout the standard.
• In the segment definition this information is
  provided in the column labeled ITEM.

76
Fields Name

• Descriptive name for the data item.
• In the segment attribute tables this information
  is provided in the column labeled ELEMENT NAME.

77
The HL7 Message

• HL7 Messages are several segments which are
  grouped together
• Segments are logical groupings of data fields
• Fields are a string of components representing
  data
• Components may contain subcomponents

78
The HL7 Message

• Message
• Segment
• Field (Data Element)
• Component
• Subcomponent
• Subcomponent
• Component
• Field
• Component
• Segment

79
The HL7 Message XML style

• ltMessagegt
• ltSegmentgt
• ltFieldgt
• ltComponentgt
• ltSubcomponentgt
• lt/Subcomponentgt
• lt/Componentgt
• lt/Fieldgt
• lt/Segmentgt
• lt/Messagegt

80
Message delimiters

• In constructing a message, certain special
  characters are used.
• Segment terminator ltcrgt
• Field separator
• Component separator
• Subcomponent separator
• Repetition separator
• Escape character \

81
Escape sequences

• \H\ start highlighting
• \N\ normal text
• \F\ field separator
• \S\ component separator
• \T\ subcomponent separator
• \R\ repetition separator
• \E\ escape character
• \Xdddd\ hexadecimal data
• \Zdddd\ locally defined escape sequence

82
HL7 message

• Message header segment, MSH
• Patient identification segment, PID
• Observation request segment, OBR
• Observation result segment, OBX
• Complete blood count, CBC

83
Segment

• Each segment contains a number of data fields.
  HL-7 defines the data type, the composition for
  fields with multiple values, and when applicable,
  the possible values for a data field.
• The example message shown below is used to
  retrieve information about electrolytes and
  complete blood count (CBC) from a given
  laboratory information system.

84
Segment

• After the headers MSH and PID, the OBR for
  electrolytic information is depicted together
  with the corresponding OBX lines.
• Subsequently, the OBR for CBC and the results are
  shown.

85
Example

• MSH...PID...ElectrolytesOBR1870930010OE
  CM3562LAB80004ELECTROLYTESR19870328153019870
  3290800401-0INTERNJOEMDLNSERSMI
  THRICHARDW.DR.[phone]This is
  requestor field 1. Requestor field
  2Diag.serv.field 1.Diag.serv.field
  2.198703311400FltCRgtOBX1ST84295NA150mm
  ol/l136-148HAF19850301ltCRgtOBX2ST84132K
  4.5mmol/l3.5-5NNF19850301ltCRgtOBX3ST82
  435CL102mmol/l94-105NNF19850301ltCRgtOBX
  4ST82374CO227mmol/l24-31NNF19850301ltCR
  gt

86

• CBCOBR2870930011OEHEM3268LAB85022CBCR19
  8703281530198703290800401-0
  INTERNJOEMDLNBLDSMITHRICHARDW.
  DR.[phone]This isrequestor field
  1.This is Requestor field 2.This is lab field
  1.Labfield 2.198703311400FltCRgt
• OBX1ST718-7HEMOGLOBINLN13.4GM/DL14-18N
  SF19860522ltCRgtOBX2ST4544-3HEMATOCRITLN
  40.342-52LSF19860522ltCRgtOBX3ST789-8E
  RYTHROCYTESLN4.56106/ml4.7-6.1LSF19860
  522ltCRgtOBX4ST787-2ERYTHROCYTE MEAN
  CORPUSCULAR VOLUMELN88fl80-94NSF198605
  22ltCRgtOBX5ST785-6ERYTHROCYTE MEAN
  CORPUSCULAR HEMOGLOBINLN29.5pg27-31NNF
  19860522ltCRgtOBX6ST786-4ERYTHROCYTE MEAN
  CORPUSCULAR HEMOGLOBIN CONCENTRATIONLN3333-
  37NNF19860522ltCRgt
• OBX7ST6690-2LEUKOCYTESLN10.7103/ml4.8-
  10.8NNF19860522ltCRgtOBX8ST764-1NEUTROPHIL
  S BAND FORM/100 LEUKOCYTESLN2FltCRgtOBX9
  ST769-0NEUTROPHILS SEGMENTED/100
  LEUKOCYTESLN67FltCRgt
• OBX10ST736-9LYMPHOCYTES/100
  LEUKOCYTESLN29FltCRgtOBX11ST5905-5MON
  OCYTES/100 LEUKOCYTESLN1FltCRgtOBX12ST
  713-8EOSINOPHILS/100 LEUKOCYTESLN2FltCRgt
  

87
Data Type pp. 2-94

• 79 Composite Types
• AD (address), MO (money)
• LA1 (location variation 1)
• detailed location, e.g. room number
• 11 Primitive Types
• ST (string), TM (time), TX (text)
• NM (numeric)
• ID (coded value for HL7 defined tables)
• IS (coded value for user-defined tables)

88
Field (Data Element)

• A field is a kind of data element
• A data element is a data type within a specific
  domain
• Insurer Address XAD
• Patient Address XAD
• Home Phone XTN
• Business Phone XTN

89
Segment

• A segment consists several fields
• PID (Patient ID Segment)
• EVN (Event Type Segment)
• PV1 (Patient Visit Segment)
• PV2 (Patient Visit Additional Information
  Segment)
• NK1 (Next of Kin/Associated Parties Segment)

90
Segment

• AL1 (Patient Allergy Information Segment)
• IAM (Patient Adverse Reaction Information Segment
  Unique Identifier)
• NPU (Bed Status Update Segment)
• MRG (Merge Patient Information Segment)
• PD1 (Patient Additional Demographic Segment)
• DB1 (Disability Segment)

91
Segment

• PDA (Patient Death and Autopsy Segment)
• ROL (Role)
• DG1 (Diagnosis Information)
• DRG (Diagnosis Related Group)
• PR1 (Procedure)
• GT1 (Guarantor)
• IN1 (Insurance)
• ACC (Accident Information)

92
Segment

• UB1 (Universal Bill Information)
• UB2 (Universal Bill 92 Information)

93
Message Control Segments

• ADD (Addendum Segment)
• BHS (Batch Header Segment)
• BTS (Batch Trailer Segment)
• DSC (Continuation Pointer Segment)
• ERR (Error Segment)
• FHS (File Header Segment)
• FTS (File Trailer Segment)
• MSA (Message Acknowledge Segment)

94
Message Control Segments

• MSH (Message Header Segment)
• NTE (Notes and Comment Segment)
• OVR (Override Segment)
• SFT (Software Segment)

95
(No Transcript)
96
Option

• R Required
• RE Required but may be empty
• O Optional
• C Conditional
• CE Conditional but it may be empty
• X Not supported

97
General acknowledgment

• LAB acknowledges the message that ADT sent
  identified as ZZ9380. (LAB and ADT, the sending
  and receiving system IDs, are site-defined.)
• Both systems are associated with the same
  FACILITY, 767543.
• The AA code in the MSA segment indicates that the
  message was accepted by the application.

98
pp. 2-118

• MSH\LAB767543ADT76754319900314130405ACK
  A08ACK XX3657P2.5ltcrgt
• MSAAAZZ9380ltcrgt

99

• ACKA08ACK (Update Patient Information Event
  A08)
• ADT (Patient Administration)

100
General acknowledgement, error return

• The AR code in MSA indicates that the application
  rejected the message for functional reasons.
• MSH\LAB767543ADT767543199003141304-0500
  ACKA08ACK XX3657P2.5ltcrgt
• MSAARZZ9380 ltcrgt
• ERR PID1119103Eltcrgt

101
Message using sequence number protocol

• The sender initiates the link with a message that
  has no functional content. The sequence number is
  0. The message type and event code are not used.
• MSH\ADT767543LAB767543199003141304-0500
  ADTA08ADT_A01XX3657P2.50ltcrgt

102
pp. 2-119

• The responder uses a general acknowledgment. The
  expected sequence number is 1.
• MSH\LAB767543ADT767543199003141304-0500
  ACKA08ACK ZZ9380P2.5ltcrgt
• MSAAAXX36571ltcrgt

103
Admit/visit notification - event A01 (admitted
patient) pp. 3-150

• MSH\ADT1MCMLABADTMCM198808181126SECURITY
  ADTA01ADT_A01MSG00001P2.5ltcrgt
• EVNA01198808181123ltcrgt
• PID1PATID12345M11ADT1MRMCM123456789USS
  SASSJONESWILLIAMAIII19610615MC1200 N
  ELM STREETGREENSBORONC27401-1020GL(919)379-
  1212(919)271-3434S
• PATID123450012M10ADT1ANA123456789987654N
  Cltcrgt
• NK11JONESBARBARAKWIWIFENKNEXT OF
  KINltcrgt
• PV11I2000201201004777LEBAUERSIDNEYJ.
  SURADMA0ltcrgt

104

• Patient William A. Jones, III was admitted on
  August 18, 1988 at 1123 a.m. by doctor Sidney J.
  Lebauer (004777) for surgery (SUR).
• He has been assigned to room 2012, bed 01 on
  nursing unit 2000.
• The message was sent from system ADT1 at the MCM
  site to system LABADT, also at the MCM site, on
  the same date as the admission took place, but
  three minutes after the admit.

105
Get Person Demographics (QBP) and Response (RSP)
(Events Q21 and K21)

• Query Trigger QBPQ21QBP_Q21
• Response Trigger RSPK21RSP_K21

106
an example of a Q21/K21 query/response pair of
messages

• First is the query
• MSH\CLINREGWESTCLINHOSPMPIHOSP19991212113
  5-0600QBPQ21QBP_Q211D2.5
• QPDQ21Get Person DemographicsHL7nnn1110691122
  34METRO HOSPITALMETRO HOSPITALSOUTH
  LAB
• RCPI

107

• QPD Query Parameter Definition Segment
• RCP Response Control Parameters
• MSA Message Acknowledge
• QAK Query Acknowledge
• PID Patient Identification

108

• This query is asking for demographics for the
  person identified by the identifier 112234 from
  the assigning authority METRO HOSPITAL.
• With the demographics, we want identifiers
  returned for the person from the assigning
  authorities METRO HOSPITAL and SOUTH LAB.

109
Here is a sample response

• MSH\HOSPMPIHOSPCLINREGWESTCLIN19991212113
  5-0600RSPK21RSP_K211D2.5
• MSAAA8699
• QAK111069OKQ21Get Person DemographicsHL7nnn1
  
• QPDQ21Get Person DemographicsHL7nnn1110691122
  34METRO HOSPITALMETRO HOSPITALSOUTH
  LAB
• PID112234METRO HOSPITAL98223SOUTH
  LABEverymanAdam19600614MC2101 Webster
  106OaklandCA94612

110
Pre-admit notification - event A05 (nonadmitted
patient) pp.3-151

• MSH\REGADTMCMIFENG200301061000ADTA05A
  DT_A05000001P2.5ltcrgt
• EVNA0520030106100020030110140001200301061000
  ltcrgt
• PID1191919GENHOSMRMCM371-66-9256USSSA
  SS253763MASSIEJAMESA19560129M171
  ZOBERLEINISHPEMINGMI49849""[phone](
  900)485-5344SC10199925GENHOSAN371-66-9256
  ltcrgt
• NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
  MI49849""[phone](900)545-1234(900)545
  -1200ECEMERGENCY CONTACTltcrgt
• NK12MASSIEMARYLOUMOTHER300
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)545-1234(900)545-1200ECEMERGENCY
  CONTACTltcrgt
• NK13ltcrgt
• NK14123 INDUSTRY WAYISHPEMINGMI49849""
  [phone]EMEMPLOYER19940605PROGRAMMERA
  CME SOFTWARE COMPANYltcrgt

111

• PV1O0148ADDISON,JAMES0148ADDISON,JAMES0
  148ADDISON,JAMESAMB0148ADDISON,JAMESS1
  400AGENHOSltcrgt
• PV22003011014002
  00301101400ltcrgt
• OBXST1010.1BODY WEIGHT62kgFltcrgt
• OBXST1010.1HEIGHT190cmFltcrgt
• DG1119BIOPSY00ltcrgt
• GT11MASSIEJAMES""""""""171
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)485-5344SESELF371-66-925 171
  ZOBERLEINISHPEMINGMI49849""[phone]
  MOOSES AUTO
  CLINICltcrgt
• IN110BC1BLUE CROSS171 ZOBERLEINISHPEMINGM1
  49849(900)485-53449050 OKltcrgt
• IN12""""ltcrgt

112

• Patient James A. Massie was pre-admitted on
  January 6th, 2003 for ambulatory surgery, which
  is scheduled for January 10, 2003 at 1400.
• As part of the pre-admission process, he
  specified two emergency contacts as well as
  employer, insurance, and guarantor information.
• He also was measured and weighed.
• Note that the REGADT system supports the entry of
  four NK1 type records first, second, and third
  emergency contacts and employer information. A
  third emergency contact was not provided for
  James A. Massie. However, an NK1 record must be
  sent to support snapshot mode of update.
• The REGADT system also supports entry of two
  insurance plans, one guarantor, and one diagnosis.

113
Register a patient - event A04 (nonadmitted
patient) pp. 3-151

• MSH\REGADTMCMIFENG200301101501ADTA04A
  DT_A01000001P2.5ltcrgt
• EVNA0420030110150020030110140001200301101410
  ltcrgt
• PID191919GENHOSMR371-66-9256USSSASS25
  3763MASSIEJAMESA19560129M171
  ZOBERLEINISHPEMINGMI49849""[phone](
  900)485-5344SC10199925GENHOSAN371-66-9256
  ltcrgt
• NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
  MI49849""[phone](900)545-1234(900)545
  -1200EC1FIRST EMERGENCY CONTACTltcrgt

114

• NK12MASSIEMARYLOUMOTHER300
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)545-1234(900)545-1200EC2SECOND EMERGENCY
  CONTACTltcrgt
• NK13ltcrgt
• NK14123 INDUSTRY WAYISHPEMINGMI49849""
  [phone]EMEMPLOYER19940605PROGRAMMERA
  CME SOFTWARE COMPANYltcrgt
• PV1OO/R0148ADDISON,JAMES0148ADDISON,JAME
  S0148ADDISON,JAMESAMB0148ADDISON,JAMES
  S1400AGENHOS199501101410
  ltcrgt
• PV22003011014002
  00301101400ltcrgt
• OBXST1010.1BODY WEIGHT62kgFltcrgt
• OBXST1010.1HEIGHT190cmFltcrgt
• DG1119BIOPSY00ltcrgt
• GT11MASSIEJAMES""""""""171
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)485-5344SESELF371-66-925MOOSES
  AUTO CLINIC171 ZOBERLEINISHPEMINGMI49849""(
  900)485-5344ltcrgt
• IN100BC1BLUE CROSS171 ZOBERLEINISHPEMINGM1
  49849""(900)485-53449050 OKltcrgt
• IN12""""ltcrgt

115

• Patient James A. Massie arrived at location O/R
  for surgery on January 10th, 2003 at 1410 for
  ambulatory surgery which was scheduled for
  January 10, 2003 at 1400.
• The visit event was recorded into the MCM system
  on January 10, 2003 at 1500.
• It was sent to the interface engine (IFENG) at
  1501.

116
Change an outpatient to an inpatient - event A06
pp. 3-152

• MSH\REGADTMCMIFENG200301110025ADTA06A
  DT_A06000001P2.5ltcrgt
• EVNA062003011002501200301102300ltcrgt
• PID191919GENHOSMRFAC1371-66- 9256USSSA
  SS253763MASSIEJAMESA19560129M171
  ZOBERLEINISHPEMINGMI49849""[phone](
  900)485-5344SC10199925GENHOSAN371-66-9256
  ltcrgt
• NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
  MI49849""[phone](900)545-1234(900)545
  -1200EC1FIRST EMERGENCY CONTACTltcrgt
• NK12MASSIEMARYLOUMOTHER300
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)545-1234(900)545-1200EC2SECOND EMERGENCY
  CONTACTltcrgt
• NK13ltcrgt
• NK14123 INDUSTRY WAYISHPEMINGMI49849""
  [phone]EMEMPLOYER19940605PROGRAMMERA
  CME SOFTWARE COMPANYltcrgt

117

• PV1I6N1234AGENHOS0100ANDERSON,CARL0148
  ADDISON,JAMESSUR0148ANDERSON,CARLS140
  0AGENHOS199501102300ltcrgt
  
• OBXST1010.1BODY WEIGHT62kgFltcrgt
• OBXST1010.1HEIGHT190cmFltcrgt
• DG1119BIOPSY00ltcrgt
• GT11MASSIEJAMES""""""""171
  ZOBERLEINISHPEMINGMI49849""[phone](9
  00)485-5344SESELF371-66-925MOOSES
  AUTOCLINIC171ZOBERLEINISHPEMINGMI49849""(90
  0)485-5344ltcrgt
• IN100BC1BLUE CROSS171 ZOBERLEINISHPEMINGM1
  49849""(900)485-53449050 OKltcrgt
• IN12""""ltcrgt

118

• Patient James A. Massie was later converted to an
  inpatient on January 10th, 2003 at 2300 to
  recover from the operation.
• The change from outpatient to inpatient was
  recorded on the MCM system on January 11, 2003 at
  0025.
• He was assigned to room 1234, bed A on unit 6N.
  When Patient James A. Massie was converted to an
  inpatient on January 10th, 2003 at 2300, his
  hospital service changed to SUR.
• His attending doctor and admitting doctors
  changed to Dr. Carl Anderson.

119
Sample ADT Message (1)

• MSH\ST01ACM01A1994091310500102ADTA010
  02988538062171P2.21
• EVNA01199409131050
• PID88888EMI
• Primary99999LABU6123456HowserDoogieBJr.S
  irPhDBabasafa1961
• 0521MaleHowserDogBrace123 Looney Toon
  WaySte 123Toon
• TownCA95403USAHome(707)578-4098(707)541-
• 2583EnglishMCatholic3444-55-
• 6666555555555CAMothersIdentifierethnicModesto
  N1USA
• NK1BelleClaraASister123 Toon Tower
  RdToon
• TownCA95403USAB(707)538-9141(707)234-
• 1234Emergency1995082619950830DaycareDC434-32
  -1232Toon Daycare
• NK1BelleBruceABrotherContact19950826
  19950830DC

120
Sample ADT Message (2)

• PV1Inpatient/Acute1ESTROOM2BEDAFAC01Aafl
  avFlavershumAlexander
• Dr.200SmuckShirleyDr.MEDICINE/CARDIOLOGY
  0003
• 199508261025199508301050
• DG1ICD910.1Hopeless Diagnosis199508271035Adm
  itting
• AL1FAALCODEAllergic to Roadrunners10Sneezing
  
• GT1Acme Insurance100 Looney StreetDisney
  DistrictToon
• CityCA90505USA(709)333-3333(709)444-
• 4444Self1994010119980101McKessonHBOC123
  Employer
• AddressAddress Line 2Toon CityCA90505USA(707
  )555-55551

121
Massage Type

• ACK General acknowledgment message
• ADR ADT response
• ADT ADT message
• BAR Add/change billing account
• BPS Blood product dispense status message
• BRP Blood product dispense status acknowledgement
  message

122
XML Encoding

• Use XML tags to replace separators
• Backward compatibility
• World-wide Standard

123
Sample Trigger Events

• ADT Trigger Events
• A01 Admit/Visit Notification
• A02 Transfer a Patient
• A03 Discharge/End Visit
• A08 Update Patient Information
• Order Trigger Events
• O01 Order Message
• Result Trigger Events
• R01 Unsolicited Transmission of Requested
  Observation
• Master File Trigger Events
• M02 Master File - Staff Master File - Staff
  Practitioner

124
Hierarchy of Identifiers

• These events assume a hierarchy of identifiers
  exists between person, patient, account, and
  visit. The hierarchy is as follows
• Level 3 - Patient (identified by PID-3 - Patient
  Identifier List)
• Level 2 - Account (identified by PID-18 -
  Patient Account Number)
• Level 1 - Visit (identified by PV1-19 - Visit
  Number)

125
How to use HL7?
Medical Record
Scheduling
Physician Order
?
?
126
Different View
Physician
HL7 Message
Nurse
Counter
127
Different View (2)
Physician
HL7 Message
Programmer
User
Nurse
Counter
128
How to do it?

• Database Integrator
• Receive response HL7 messages
• Dispatch message and manage DBs
• System Analyzer
• Use HL7 to design systems
• Developer
• Send HL7 message to access database
• Design business components
• Design User-Interface

129
Data layer security (HL7 subsystem)
System A
System B
Database
System C
130
Solutions

• Data exchange middleware
• Common exchange standard
• Trigger event for database synchronization
• Common gateway for data-layer security
• Agreement for all subsystems

131
Middleware (blue blocks)
Web Server
AP Server
Database
Physician
Nurse
Counter
132
HL7 Structure
Patient Administration
Personnel Mgt.
Master Files
CDA
Scheduling
Med. Rec/Info Mgt.
Observation Reporting
Query
Arden Syntax
Order Entry
Patient Care
Clinical Lab Auto.
MMS
Referral
Financial Management
Application Mgt.
Customization Required
133

• MMS Material Management System
• AsmProxy is a class of C codes (which is always
  named as assembly codes in C.NET document).
• AsmProxy is a dynamic class loader for loading
  HL7Central_IIS subsystem into HL7Central_IIS.
• HL7Secondary is a subsystem for data exchange
  among HL7 subsystems. That is, HL7Central_IIS
  will send messages to MSMQ and HL7Secondary
  will retrieve messages from MSMQ.

134
Document Management

• Document Status
• Document Content Management
• Document Query

135
Observation Reporting

• Laboratory Observation
• Clinical Trials
• Product Experience
• Waveform

136
Order Entry

• General Order
• Dietary Order
• Supply Order
• Pharmacy/Treatment Order
• Vaccine Order
• Transfusion Order

137
Patient Care

• Goal Add/Update/Delete
• Problem Add/Update/Delete
• Pathway Add/Update/Delete
• Query

138
Patient Administration

• Register a patient
• Patient location tracking
• Patient information insert/delete/update
• Query patient information

139
Master Files

• Staff practitioner master files
• Service/Test/Observation master files
• Location master files
• Charge description master files
• Clinical trials master files

140
Personnel Management

• Add/Update/Delete personnel record
• Activate/Deactivate practicing person
• Grant/Revoke permissions
• Query personnel records

141
Registration Flow
Start registration
New patient?
Input/Add patient information
Query
ADT
Input visit/appoint. information
ADT
Register patient create account
Scheduling
Master
Financial
OK
142
HL7 Central Architecture
143
Objectives

• Rapid dispatching of HL7 messages
• Reliable execution environment for subsystems
• Effective secondary message processing
• Simple template for HL7 message handler
  programming

144
Central Architecture
Web Application
HL7
IIS (asp_net.exe)
HL7 Central_IIS
145

• IIS Internet Information Service
• MSMQ Microsoft Message Queue

146
Secondary Processing
MSMQ/Remoting
HL7 Secondary Windows Service
147
AppDomain Protection
Message Dispatcher
HL7 Central_IIS
AsmProxy
148
IIS Worker Threads
Web Application
HL7
IIS (asp_net.exe)
149
Features

• Search UI template
• Wizard UI template
• Fail protection
• Transaction error handling

150
Static Performance Estimation

• Hardware Spec
• Intel 3.0 GHz
• 768 MB RAM
• Windows Server 2003 Enterprise
• 14 Blades for Web Service Tier
• 2 CPU
• 2 GB Memory
• 300 messages 14 4200 messages / s

151
Development Process

• System analysis with HL7 subsystem concept
• Mapping the database fields and HL7 messages
• Designing UI with UI template
• Coding with HL7 library
• HL7Message.dll
• CommonLib.dll/CommonLibUI.dll

152
HL7 Database Global view
153
SOA Architecture HL7

• Roadmap from now on

154
Software Architecture
Web Applications
Windows Applications
???????????????UI
CommonLibUI.dll
????AP????AP Server???????
NTUH Web Services
Authenticate/Authorize
Session Service
?????????,??UI????????
CommonLib.dll
??Web Service?????????????
Oracle Database Server
????????????,??CommonLib??
155
Design Flow
Start A Project
System Analysis Design
Configuration
Environment Setup
Web Service/Web Application Programming
156
Example

• lt?xml version"1.0" encoding"utf-8"?gt
• ltMenuItem Name"????"gt
• ltMenuItem Name"??"gt
• ltMenuItem ID"BloodBank/NewBCBloodBag"
  Name"??????" ShortName"??????"/gt
• ltMenuItem ID"BloodBank/NewSpBloodBag"
  Name"????" ShortName"????"/gt
• ltMenuItem ID"BloodBank/QryStockIn"
  Name"??????" ShortName"??????"/gt
• lt/MenuItemgt
• ltMenuItem Name"????"gt
• ltMenuItem ID"BloodBank/QryDueBags"
  Name"????????" ShortName"????????"/gt
• ltMenuItem ID"BloodBank/BagDump" Name"??????"
  ShortName"??????"/gt
• ltMenuItem ID"BloodBank/BagTrasfer" Name"????"
  ShortName"????"/gt
• ltMenuItem ID"BloodBank/InvCheck" Name"????"
  ShortName"????"/gt
• ltMenuItem ID"BloodBank/UpdMissingBag"
  Name"??????" ShortName"??????"/gt
• ltMenuItem ID"BloodBank/BCReport" Name"????"
  ShortName"????"/gt
• ltMenuItem ID"BloodBank/QryStockOutDetails"
  Name"??????" ShortName"??????"/gt
• lt/MenuItemgt
• lt/MenuItemgt

PageID.xml
157
PageID URL
From System
PageID
BloodBank/NewBCBloodBag
172.16.72.1/WebApplication/

• http//172.16.72.1/WebApplication/BloodBank/NewBCB
  loodBag.aspx

Project Name
File Name
158
PageID

• ??????????????(Role)????????????????,
  ?????????????????????
• ?, ??? ?? ??
• ??????????????, ?????????????PageID,
  ?????????????, ????????????????
• ?, ??? ??

159
CommonLib(UI) 1.x

• Passing Security Information via SOAP Header
• Method Invocation
• Service (type)CommonLibUI.Config.InitService(thi
  s, typeof(type))
• Service.Method1(a, b, )
• Method Implementation
• Public AuthHeader Credentials
• AuthExtension
• SoapHeader ("Credentials")
• WebMethod

160
CommonLibUI 1.x

• Authentication Authorization
• Config.InitPage(this, "BloodBank/NewBCBloodBag")
• Menu Generation UI
• Config.InitControl(this, NTUHWeb1)
• Web Service Security
• serv (localhost.Service1) Config.InitService(thi
  s, typeof(localhost.Service1))

161
Authentication Authorization
Web Application
CommonLibUI
Session Web Services
InitPage
Check Session
Request
Session OK
InitPage OK
SQL Server
Code Generation
Request
Check Permission
Response
Permission OK
Generation OK
Redirect
162
???????

• ???????
• ???????
• ??????????
• ????,?????????????
• ??????
• ?????
• Audi VW??
• PC AT/XT

163
?????
????
????
????
????(?)
????
????(?)
164
???????

• ????
• ??????????
• ??????????
• ??????
• ???????????
• ????HL7??
• ???????????