Health Information Standard HL7 - PowerPoint PPT Presentation

1 / 164
About This Presentation
Title:

Health Information Standard HL7

Description:

... a recommendation for using XML as an alternative syntax for HL7 V2.3.1 messages. ... Arden Syntax for Medical Logic Systems ... – PowerPoint PPT presentation

Number of Views:516
Avg rating:3.0/5.0
Slides: 165
Provided by: fei7
Category:

less

Transcript and Presenter's Notes

Title: 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.(319)377-4400This 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.(319)377-4400This 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""(900)485-5344(
    900)485-5344SC10199925GENHOSAN371-66-9256
    ltcrgt
  • NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
    MI49849""(900)485-5344(900)545-1234(900)545
    -1200ECEMERGENCY CONTACTltcrgt
  • NK12MASSIEMARYLOUMOTHER300
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(9
    00)545-1234(900)545-1200ECEMERGENCY
    CONTACTltcrgt
  • NK13ltcrgt
  • NK14123 INDUSTRY WAYISHPEMINGMI49849""
    (900)545-1200EMEMPLOYER19940605PROGRAMMERA
    CME SOFTWARE COMPANYltcrgt

111
  • PV1O0148ADDISON,JAMES0148ADDISON,JAMES0
    148ADDISON,JAMESAMB0148ADDISON,JAMESS1
    400AGENHOSltcrgt
  • PV22003011014002
    00301101400ltcrgt
  • OBXST1010.1BODY WEIGHT62kgFltcrgt
  • OBXST1010.1HEIGHT190cmFltcrgt
  • DG1119BIOPSY00ltcrgt
  • GT11MASSIEJAMES""""""""171
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(9
    00)485-5344SESELF371-66-925 171
    ZOBERLEINISHPEMINGMI49849""(900)485-5344
    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""(900)485-5344(
    900)485-5344SC10199925GENHOSAN371-66-9256
    ltcrgt
  • NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
    MI49849""(900)485-5344(900)545-1234(900)545
    -1200EC1FIRST EMERGENCY CONTACTltcrgt

114
  • NK12MASSIEMARYLOUMOTHER300
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(9
    00)545-1234(900)545-1200EC2SECOND EMERGENCY
    CONTACTltcrgt
  • NK13ltcrgt
  • NK14123 INDUSTRY WAYISHPEMINGMI49849""
    (900)545-1200EMEMPLOYER19940605PROGRAMMERA
    CME SOFTWARE COMPANYltcrgt
  • PV1OO/R0148ADDISON,JAMES0148ADDISON,JAME
    S0148ADDISON,JAMESAMB0148ADDISON,JAMES
    S1400AGENHOS199501101410
    ltcrgt
  • PV22003011014002
    00301101400ltcrgt
  • OBXST1010.1BODY WEIGHT62kgFltcrgt
  • OBXST1010.1HEIGHT190cmFltcrgt
  • DG1119BIOPSY00ltcrgt
  • GT11MASSIEJAMES""""""""171
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(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""(900)485-5344(
    900)485-5344SC10199925GENHOSAN371-66-9256
    ltcrgt
  • NK11MASSIEELLENSPOUSE171 ZOBERLEINISHPEMING
    MI49849""(900)485-5344(900)545-1234(900)545
    -1200EC1FIRST EMERGENCY CONTACTltcrgt
  • NK12MASSIEMARYLOUMOTHER300
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(9
    00)545-1234(900)545-1200EC2SECOND EMERGENCY
    CONTACTltcrgt
  • NK13ltcrgt
  • NK14123 INDUSTRY WAYISHPEMINGMI49849""
    (900)545-1200EMEMPLOYER19940605PROGRAMMERA
    CME SOFTWARE COMPANYltcrgt

117
  • PV1I6N1234AGENHOS0100ANDERSON,CARL0148
    ADDISON,JAMESSUR0148ANDERSON,CARLS140
    0AGENHOS199501102300ltcrgt
  • OBXST1010.1BODY WEIGHT62kgFltcrgt
  • OBXST1010.1HEIGHT190cmFltcrgt
  • DG1119BIOPSY00ltcrgt
  • GT11MASSIEJAMES""""""""171
    ZOBERLEINISHPEMINGMI49849""(900)485-5344(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??
  • ???????????
Write a Comment
User Comments (0)
About PowerShow.com