HL7V3 and ebXML - Part 1

In 2003 HL7 Board of Directors approved usage of ebXML for transporting HL7V3 messages as Draft Standard for Trail Use (DSTU) . The English Connecting for Health is one of the first major users of this transport and all HL7V3 asynchronous messages communications in that project is performed using ebXML. This is the first of blogs to understand the relationship between HL7v3 and ebXML . In this process we will also discuss the structure of HL7V3 message as well.


Figure below shows the general structure and composition of an ebXML message

The ebXML Message is a MIME/Multipart message envelope structured in compliance with the SOAP Messages with Attachments specification and is referred to as Message Package.

The Message Package is divided logically into two MIME parts

• A MIME part, referred to as Header Container containing one SOAP 1.1 compliant message. This message is referred to as SOAP message



• Zero or more additional MIME parts referred to as Payload Containers containing application level payloads

The SOAP Message is an XML document that consists of the SOAP Envelope element. The SOAP Envelope element consists of the following:

• SOAP Header element - This is a generic mechanism for adding features to a SOAP Message, including ebXML specific header elements.



• SOAP Body element. - This is a container for message service handler control data and information related to the payload parts of the message.

In this post let’s discuss the first MIME part containing the SOAP envelope. Let me take an example of ebXML wrapper and run through so that the context can be understood.

Now let us analyse the wrapper in detail

--------------------------------------------------------

<soap-env:Envelope

xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" >
<soap-env:Header>
<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">
<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1 </eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>
<eb:CPAId>ABC22</eb:CPAId>
<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:ConversationId>
<eb:Service>urn:org:names:services:MPI</eb:Service>
<eb:Action>PRPA_IN040000UV15</eb:Action>
<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>
<eb:DuplicateElimination/>
</eb:MessageHeader>
<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH" />
</soap-env:Header>
<soap-env:Body>
<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
<soap-env:Envelope>

----------------------------------------------------

1. The wrapper starts with name space declaration

<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd >

Name space declaration for the ebXML SOAP extensions may be included in the SOAP Envelope, Header or Body elements, or directly in each of the ebXML SOAP extension elements.

The SOAP namespace: “http://schemas.xmlsoap.org/soap/envelope/ “ resolves to a W3C XML Schema specification. The ebXML OASIS ebXML Messaging TC has provided an equivalent version of the SOAP schema conforming to the W3C Recommendation version of the XML Schema specification
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd

The XML schema-instance namespace qualified schemaLocation attribute in the SOAP envelope to indicate to validating parsers a location of the schema document should be used to validate the document is also included.
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd


[HL7-ebXML] extends the ebXML headers within the HL7 ebXML namespace. The namespace declaration for the extensions has a required value of:
xmlns:hl7ebxml=”urn:hl7-org:transport/ebxml/DSTUv1.0”

2. The next is SOAP Header Element

<soap-env:header>

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is a element indicating the required transport state to the next SOAP node.

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is an element indicating the required transport state to the next SOAP node.

3. The Message Header starts with Version and SOAPUnderstand attribute as shown below

<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">

The REQUIRED version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

4. The next element is the From Element

<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1</eb:PartyId>
</eb:From>

The REQUIRED From element identifies the Party that originated the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attributeindicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

5. The next element is the To Element

<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>

The REQUIRED To element identifies the Party that is the intended recipient of the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attribute indicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

6.The CPAId element is a string that identifies the parameters governing the exchange of messages between the parties.

<eb:CPAId>ABC22</eb:CPAId>

The recipient of a message MUST be able to resolve the CPAId to an individual set of parameters, taking into account the sender of the message. The value of a CPAId element MUST be unique within a namespace mutually agreed by the two parties. The value ABC22 reference the contract properties assigned to each service/action.

7. The ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId.

<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7 </eb:ConversationId>

The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent.

8. The Service element identifies the service that acts on the message and it is specified by the designer of the service

<eb:Service>urn:org:names:services:MPI</eb:Service>

The designer of the service may be:
• a standards organization, or
• an individual or enterprise

The above value indicates that it has something to do with the Master Patient Index

9.The Action element identifies a process within a Service that processes the Message. Action SHALL be unique within the Service in which it is defined

<eb:Action>PRPA_IN040000UV15</eb:Action>

The value of the Action element is specified by the designer of the service. The above value is the message interaction that is sent with this ebXML wrapper and used for the MPI service.

10. The MessageData element provides a means of uniquely identifying an ebXML Message. It contains the following:

MessageId element
Timestamp element
RefToMessageId element

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>

MessageId is a globally unique identifier for each message conforming to MessageId.

Timestamp is a value representing the time that the message header was created conforming to a dateTime [XMLSchema] and MUST be expressed as UTC

RefToMessageId element has a cardinality of zero or one. When present, it MUST contain the MessageId value of an earlier ebXML Message to which this message relates. If there is no earlier related message, the element MUST NOT be present. For example if is present the Message Data will be something like

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
<eb:RefToMessageId>39E66A20-2DD3-22B3-91FA-81CE4147A4A7 </eb:RefToMessageId>

11.The DuplicateElimination element, if present, identifies a request by the sender for the receiving MSH to check for duplicate messages

<eb:DuplicateElimination/>

12. The AckRequested element is an OPTIONAL extension to the SOAP Header used by the Sending MSH to request a Receiving MSH, acting in the role of the actor URI identified in the SOAP actor attribute, returns an Acknowledgment Message. The AckRequested element contains the following:

• a version attribute
• a SOAP mustUnderstand attribute with a value of "1"
• a SOAP actor attribute
• a signed attribute

<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml- msg:actor:toPartyMHS" />

The SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".


The AckRequested element MUST be targeted at either the Next MSH or the To Party MSH (these are equivalent for single-hop routing). This is accomplished by including a SOAP actor with a URN value with one of the two ebXML actor URNs defined in sections 2.3.10 and 2.3.11 or by leaving this attribute out. The default actor targets the To Party MSH.


The REQUIRED signed attribute is used by a From Party to indicate whether or not a message received by the To Party MSH should result in the To Party returning a signed Acknowledgment Message – containing a [XMLDSIG] Signature element . Valid values for signed are:
true - a signed Acknowledgment Message is requested, or
false - an unsigned Acknowledgment Message is requested

13.The Manifest element identifies the payload messages that are carried with the ebXML message. Manifest is included in the SOAP:Body. These references can be:

· References to the attached MIME parts using the cid reference mechanism.
· References to remote content not included in the message but accessible via other means and referenced via a URI

<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The Reference element is a composite element consisting of the following subordinate elements:
• zero or more Schema elements – information about the schema(s) that define the instance document identified in the parent Reference element
• zero or more Description elements – a textual description of the payload object referenced by the parent Reference element

The Reference element itself is a simple link [XLINK]. In this context it has the following attribute content

xlink:href – this REQUIRED attribute has a value that is the URI of the payload object referenced. It SHALL conform to the XLINK [XLINK] specification criteria for a simple link.

The schema element provides a means of identifying the schema and its version defining the payload object identified by the parent Reference element. The Schema element contains the following attributes:
• location – the REQUIRED URI of the schema
• version – a version identifier of the schema


The final element is the payload element. This element contains style or standard to which the message in the payload conforms. In this case it is “HL7". It contains the encoding method for the standard which is used to encode the message in the payload. For HL7v3.0 we use "XML". Finally the version of the standard to which the payload message conforms and for HL7V3.0 its 3.0.

The HL7V3.0 Primer

What is HL7V3.0 ?

HL7V3.0 is a model based messaging specification which was proposed to resolve the weaknesses of HL7V2.x. The aim of a model based messaging standard is to create a standard set of structures for the sharing of healthcare information and support binding of standard clinical terminologies to the model. The creation of a standard clinical model with standard terminology establishes a healthcare domain specific common language which would allow any healthcare application model to map onto the reference model. This mapping would allow interoperability with other applications apart from allowing re-use of healthcare data in the application which has mapped its model onto the model.

Methodology Overview

Figure below shows the methodology used in HL7V3.0

The different processes in the HL7V3.0 methodology to obtain the message specifications are described below

Use Case Modeling:

The Use case Model consists of the following definitions

Ø Scope statement: A high level use case for the entire project

Ø Use case: Describes specific situations in which communication between healthcare entities is needed

Ø Actor: An entity which initiates or participates in the use case. Discovered in the process of developing use cases

Ø Use Case Diagram: Provides a graphical form to develop the use case model from the business process analysis and makes it easy to show the relationship between use cases

Interaction Modeling:

The Interaction Model

Ø Describes roles to which systems may claim conformance

Ø Fine-grained abstraction; every system will claim several roles

Ø Not standardizing system or application functions, only messaging roles

Ø Basis for contractual agreement

Ø Potential basis for conformance testing

Ø Captured in a MODEL, a TABLE, and a DIAGRAM

Each Interaction consists of:

Ø Trigger event :Event dependency usually expressed as the state of one or more classes

Ø Message ID : Each interaction sends one particular message

Ø Sender role

Ø Receiver role

Ø Receiver responsibility :A specific functional responsibility for the receiver to initiate another (consequential) interaction

Information Modeling:

The information model consists of the following

Ø A detailed and precise definition for the information from which the data content of HL7 messages are drawn.

Ø Follows object-oriented modeling and diagramming techniques, and is centered on a depiction of the classes that form the basis for the objects in HL7 messages.

Ø Provides a means for expressing and reconciling differences in data definition independent of message structure.

Ø Forms a shared view of the information domain used across all HL7 messages.

The Information Model defines

Ø classes, attributes, data types, and relationships

Ø vocabulary domains, code systems, and value sets

Ø states, trigger events, and transitions

Reference Information Model:

The model which forms the basis for the development of HL7V3.0 message specifications labeled RIM (Reference Information Model) is an object oriented model where the information is organized into classes that have attributes and that maintain associations with other classes. The information-related content of HL7 3.0 protocol specification standards is drawn from this model. RIM uses notation based on the Uniform Modeling Language (UML) and information modeling conventions outlined in the HL7 message development framework. RIM provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

RIM is conveniently fashioned into three areas – semantic control, structured documents and message control.

The backbone of RIM consists of four primary classes and two linking classes. The four primary classes in the semantic content partition of the RIM are

Act: An Act is defined as intentional healthcare related action in the business domain of HL7. An instance is a record of an act. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. An act is represented by a brick colored block in the RIM as following example

Act has the following sub-classes

Ø Account

Ø ControlAct

Ø DeviceTask

Ø DiagnosticImage
Ø Diet

Ø FinancialContract

Ø FinancialTransaction

Ø InvoiceElement

Ø Observation

Ø Participation

Ø PatientEncounter

Ø Procedure

Ø PublicHealthCase

Ø SubstanceAdministration

Ø Supply

Ø WorkingList

Entity: Entity is a physical thing or organization and grouping of physical things. A physical thing is anything that has extent in space, mass. Excludes information structures, electronic medical records, messages, data structures, etc. An Entity is represented by a green colored block in the RIM as following example

Entity has the following sub-classes

Ø Container
Ø Device

Ø LanguageCommunication

Ø LivingSubject

Ø ManufacturedMaterial

Ø Material

Ø NonPersonLivingSubject

Ø Organization

Ø Person

Ø Place

Role : For people, role is usually positions, jobs, or ‘hats’ and for places and things are what these places or things are normally used for. Each role is “played by” one Entity and is usually “scoped” by another. Thus the role of Patient is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, an Employee role is scoped by the employer. A role is represented by a yellow colored block in the RIM as follows



Role has the following sub-classes:

Ø Access
Ø Employee

Ø LicensedEntity

Ø Patient

Participation: Role exists only within the scope of one act. Acts have multiple participants, each of which is an entity in a role. Role signifies competence while participation signifies performance. Participation is represented in the RIM by the following block

Participation has ManagedParticipation sub-class.

Act Relationship: ActRelationship is association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance.Act Relationship is represented in RIM by the following block

ActRelationship has no sub-classes

Role Link: Role Link is a relationship between two entity roles. For example Clinicians relationship with a Hospital and a Patients relationship with a Hospital to express the doctor and patient relationship. Role Link is represented in RIM by the following block

RIM Classes Example

Figure below shows the relationships between the different classes in the RIM with an example

In the above example the Act Examination is performed by Entity Person A in his role as GP and the Subject of the Examination is the Entity Person B in his role as Patient.

Attributes:

Class attributes are the core components of the information model. The attributes are the source for all the information content of HL7. There are three special kinds of attributes in the information model: identifier attributes, classifier attributes and state attributes.

Ø Identifier attributes: Identifier attributes can be used to identify an instance of a class. Values of identifier attributes never change. Examples of identifier attributes from the RIM include Entity.id and Act.id, which uniquely identify a particular Entity or Act respectively

Ø Classifier Attributes: The classifier attributes are a critical aspect of the classes forming the backbone of the RIM. The classifier attributes are named "classCode".

Ø Structural Attributes: Structural attributes are those attributes whose coded values are needed to fully interpret the classes that they classify. ClassCode together with moodCode, typeCode and determinerCode are the structural attributes.

Ø State Attributes: A state attribute is used in subject classes (classes that a Technical Committee designates as the central focus of a collection of messages). It contains a value that concisely indicates the current state (named condition) of the class.

Message Design:

The Message Design in HL7V3 from RIM is obtained as follows Message Design Overview

Domain Message Information Model:

DMIM is

Ø Full description (model) of the information classes within a domain and the way in which they are being used

Ø Classes are ‘cloned’ (copied and adapted) and renamed (alias) according to the way they are used in the domain context

Ø Data Types and vocabulary for attributes are specified

Ø Every RIM class category has its own colour; this makes the model description more visual

To obtain D-MIM from RIM

Ø Select RIM classes to be included in D-MIM Select the subset of RIM classes relevant to the problem domain.

Ø Clone subset classes of the RIM If the same RIM class is selected to meet different information needs then create as many clones of the RIM base class as needed. Ø Select a subset of class relationships Add relationships between the D-MIM clones consistent with existing class relationships in the RIM.

Ø Select a subset of class attributes For each D-MIM clone select the applicable attributes from its RIM base class.

Ø Select a subset of attribute data types and vocabulary domains Assign data types and domains to D-MIM attributes that are consistent with assigned data types and domains in the RIM

Refined Message Information Model:

R-MIM is

Ø Same type of representation as D-MIM

Ø Aimed for a specific category of interaction (e.g. all inpatient admission related messages) Ø Special form of an R-MIM are the Common Message Element Types (CMETs).These express common and reusable ‘information units’, that are derived from a D-MIM (like all R-MIMs) but can be used in other D-MIMs (and therefore R-MIMs) as building blocks (e.g. ‘patient’)

To obtain R-MIM from D-MIM

Ø Create clones of D-MIM classes and attributes Further specialize D-MIM classes by creating additional clones for each unique collection of attributes

Ø Assign alias class and relationship role names Assign domain specific names to class clones Ø Eliminate unnecessary class hierarchies Remove classes with no attributes and relationships from the class hierarchy

Ø Finalize class relationships and cardinality Alter relationship cardinality to reflect the appropriate minimum and maximum class occurrences

Ø Finalize attribute data types and domains Replace data type and domain specifications with the most appropriate constrained version of each

Hierarchical Message Definition

HMD is a further restriction of an R-MIM:sequentialized/serialized; represented in a different format. To create a HMD

Ø Select a root class for the message Chose a class to serve as the starting point for message content

Ø Arrange classes and attributes hierarchically Follow the relationships from class to class and add the attributes to the HMD.

Ø Declare inclusion and repetition constraints For each attribute specify if its presence in message content is optional, mandatory, or conditional and specify the number of times the attribute may repeat

Ø Declare data type and domain value constraints Declare additional constraints on the data types and domain values

Ø Assign message element names Assign a final meaningful business name to each attribute in the HMD

HL7 V3.0 Data Types:

HL7 data types define the structure and constrain the allowable values of attributes in the RIM. The HL7 data type specification declares the set of data types, identifies components of complex types, and defines relationships between data types. The HL7 data type implementation technology specification defines constraints and operations for data types and describes how data types are to be represented in XML. Data types are reusable atomic building blocks used to create all HL7 V3 information structures. Each RIM attribute is assigned one data type; each data type is assigned to zero, one, or more RIM attribute. Few of HL7V3.0 data types are given below

• AD: Postal Address
• ANY: DataValue

• BAG: Bag

• BL: Boolean

• CD: Concept Descriptor

• CE: Coded With Equivalents

• CS: Coded Simple Value

• ED: Encapsulated Data

• EN: Entity Name

• GTS: General Timing Specification

• HIST: History

• II: Instance Identifier

• INT: Integer Number
• IVL: Interval
• LIST: Sequence
• MO: Monetary Amount
• ON: Organization Name
• PN: Person Name
• PPD: Parametric Probability Distribution
• PQ: Physical Quantity
• REAL: Real Number
• RTO: Ratio
• SC: Character String with Code
• SET: Set
• ST: Character String
• TEL: Telecommunication Address
• TN: Trivial Name
• TS: Point in Time
• UVP: Uncertain Value - Probabilistic

HL7V3.0 Vocabulary Specification:

The HL7 V3 Vocabulary Specification defines vocabulary domains used in RIM coded Attributes and coded data type properties. A vocabulary domain is an abstract collection of interrelated concepts. It describes the purpose or intent of a coded attribute. A value set is a collection of coded concepts drawn from a single code system. A vocabulary domain may be associated with many value sets. A context expression provides a means of designating which value sets within a given domain are applicable for a given usage context. A coded concept has a concept code assigned by the coding system and a concept designation which names the referenced concept. A coded concept may be a parent concept for a collection of additional concepts within the same code system.

HL7 XML Schema Generator:

The HMD’s constrained with HL7 Vocabulary Specification and HL7 Data Type specification to a HL7XML schema Generator gives the XSD the schema definition of an HL7V3.0 message. Figure below shows the set up for the generation of XSD.

Links, References, Acknowledgements and Copyright

http://www.hl7.org