|
|
|
Standard Implementation: |
|
|
|
Achieving Cost Reduction and
Improving quality through Standard Conformance |
|
|
|
|
|
HL7 Conformance Concepts |
|
Background |
|
Message Profile Specification |
|
HL7 3.x Conformance |
|
Verification, validation, certification |
|
Benefits of conformance |
|
Conformance Tools (if time allows) |
|
|
|
|
|
|
|
It was not part of HL7 from “day one” |
|
Normative in Version 2.5, it may be applied to
previous versions |
|
Version 3.0 |
|
EDI Integration for loosely-coupled clinical
application ® Process Automation |
|
Similar to ASTM, X12N |
|
Extensible (“Z” elements) |
|
|
|
|
|
|
|
“Optionality” |
|
the standard combines many use case models |
|
Extensions |
|
“Z”segments |
|
Compliance has been difficult to measure |
|
Specifying boundary conditions such as
optionality and cardinality |
|
Under-defined constraints provided in the HL7
Standard |
|
|
|
|
Methodology for producing a precise and unambiguous
specification for implementation |
|
Message profile: constrains the standard,
unambiguous |
|
Conformant Application: adheres to the
constraints of a message profile |
|
|
|
|
Interoperability issues - not “plug and play” |
|
The standard combines the collective experience
of many vendors |
|
Combination of business requirement sets
combined but not enough specificity for any given implementation, resulting
in optionality |
|
No widely accepted reference model |
|
Local extensions |
|
Lack of uniform vocabulary |
|
|
|
|
Add specificity to existing messages and
identify the specific scenarios/use cases |
|
Identify, document, and bridge semantic
differences |
|
Eliminate optionality (“implementable”) |
|
UML- Unified Methodology Language (just like V3) |
|
|
|
|
|
|
Message Profile Concepts will be part of Version
2.5 (2002) |
|
Chapter 2 - Control (in ballot) |
|
Normative message profile concepts |
|
Normative Message Profile Document DTD |
|
Chapter 5 - Query (under review) |
|
Conformance Based Queries |
|
Re-write using Message Profile methodology |
|
|
|
|
|
|
HL7 Conformance has two objectives: |
|
Interoperability |
|
Implementable message profiles |
|
Certification |
|
Conformance Statement |
|
Normative Documentation |
|
Chapter 2 |
|
Message Profile DTD/Schema |
|
Tutorial - education |
|
You are invited to participate! |
|
Bi-weekly calls |
|
List server |
|
|
|
|
|
|
|
Message Profiles |
|
Message Profile Defined |
|
Conceptual Overview |
|
Use Case Model |
|
Static Profile |
|
Dynamic Profile |
|
Profiling Concepts |
|
Profile Registration |
|
HL7 3.x Conformance |
|
|
|
|
|
|
|
Unambiguous specification of a standard HL7
message for use within a particular set of requirements |
|
Prescribes a set of precise constraints upon one
or more standard messages |
|
Supported by use case analysis and interaction
modeling |
|
Measurable |
|
What data will be passed in a message |
|
The format in which the data will be passed |
|
The acknowledgement responsibilities of the
sender and receiver |
|
|
|
|
|
HL7 Compliant, although may further constrain |
|
Static structure and content of each message |
|
The dynamic interactions |
|
Parts of a valid message profile |
|
Use Case Model |
|
Static Definition |
|
Dynamic Definition |
|
Represented as an XML document |
|
Can be
registered with HL7 |
|
May be reused by other HL7 users |
|
May be used for documentation |
|
|
|
|
|
|
|
Documents the scope and requirements for an
HL7 Message Profile or set of
Message Profiles |
|
May include a use case diagram or detailed text |
|
Provides a name that clearly and concisely
defines the exchange |
|
Defines the actors, including the sending and
receiving applications |
|
Defines the responsibilities of these actors |
|
Documents the situations in which the exchange
of a particular HL7 Message Profile is required |
|
Documents the purpose |
|
HL7 V3.0 Message Development Framework (MDF 99) |
|
|
|
|
|
|
A specification for a message structure intended
to support the use case |
|
Based on a
message defined in HL7 Std |
|
Defined at the message, segment, and field
levels |
|
HL7 compliant |
|
May further constrain |
|
Identifies only those specific elements used in
the exchange |
|
Removes all instances of optionality, defining
explicitly |
|
Segments, segment groups, fields and components
usage rules |
|
Cardinalities |
|
Value sets and coding systems. |
|
Implementation notes |
|
|
|
|
|
|
|
|
Defines interaction between the sender and
receiver |
|
Acknowledgment mode supported |
|
Conditions under which an accept and/or
application level acknowledgment is expected |
|
Always |
|
Never |
|
Only on success |
|
Only on error |
|
|
|
|
|
Interaction Model |
|
Defines specific interactions between the
applications that support message profile communication requirements |
|
Includes interaction diagrams that illustrate
the sequence of trigger event and resulting message flows between the
sending and receiving applications |
|
Dynamic can refer one to many static definitions |
|
|
|
|
|
|
|
|
|
Message Profile registration utility on the HL7
Members’ Page of the HL7 WWW (www.hl7.org/memonly/conformance) |
|
Valid Conformance Documents (XML) |
|
Message Profile Identifier generated |
|
Repository of Message Profile |
|
Catalogue of Message Profile Users (future) |
|
application name and version |
|
contact person |
|
application role (whether the application sends
or receives messages described by the profile) |
|
Search Capabilities |
|
|
|
|
|
The process by which an application’s
conformance claim in verified against the actual application implementation |
|
Certification is a very important part of
conformance |
|
Conducted by providers, national or regional
health organizations |
|
Not conducted by HL7 |
|
|
|
|
|
|
Message profile is independent of message
instance encoding - ER7/XML |
|
XML Message Instance |
|
It represents an XML document and it contains
data and meta-data (tags) as described by its schema/DTD |
|
XML DTD/Schema |
|
Contains the rules (structure, content, data
types, cardinality) for constructing and validating an XML document |
|
Version 2.xml specification from XML SIG
(informative -> normative) |
|
|
|
|
|
|
|
Chaos ® Order |
|
Consistent Documentation |
|
Lower Cost of Integration |
|
Reuse of Specification |
|
Simplified testing |
|
Similar to Version 3 |
|
“V3-ready” |
|
Chaos -> order |
|
Site Specific Profiles |
|
Supports specific needs |
|
Required of third-party application vendors |
|
RFP:Simplifies introduction/acquisition of new
applications |
|
|
|
|
|
Structured approach to eliminate ambiguity |
|
Repeatable, efficient process, traceability |
|
Focus on requirements ® Quality |
|
Acceptance criteria based on end-user
requirements |
|
Provides implementation convergence |
|
profile sharing, reuse, “a few good use cases” |
|
Constrainable vs. Implementable profiles |
|
Conformance testing and certification |
|
|
|
|
|
|
|
Reuse of similar specification |
|
closer to “plug and play” |
|
“Connect and adjust” |
|
Certification |
|
simplifies the decision making |
|
simplifies t testing |
|
On time, on track implementations |
|
|
|
|
|
|
Normative “from day one” |
|
Informative Application Roles |
|
Similar to Version 2 Conformance |
|
Version 2 implementations can become Version 3
-ready |
|
|
|
|
|
|
|
|
|
Included in the next ballot document |
|
Conformance profiles - written by HL7 to
precisely define the behavior of an application with respect to interfaces |
|
Functional |
|
Technical |
|
Conformance claim set - a list of conformance
claim IDs |
|
|
|
|
|
|
|
For those who: |
|
Design HL7 2.x messages |
|
Manage specification repositories |
|
Collaborate on varied messaging projects within
and outside of their organizations |
|
Free of charge from HL7 Web site (www.hl7.org) |
|
HL7 -> SIG -> Conformance -> Documents |
|
Encouraged by the Conformance SIG |
|
Open Source Project |
|
Call for participation |
|
It will continue to be supported within the VA
for the foreseeable future |
|
|
|
|
Rapid prototyping of message profiles derived
from standard libraries, from profile inheritance or from scratch |
|
Quick and easy alteration of existing profiles
to meet new requirements |
|
Design time comparison of profiles on an element
by element basis |
|
Linkage of data elements or constants to message
elements for a more complete specification |
|
|
|
|
Tools for storage and retrieval of profiles as
well as updating and customizing message element libraries |
|
The ability to capture and analyze ER7 messages |
|
Capability to reverse engineer specifications
from captured messages. |
|
A suite of reports that document specifications
and produce example messages in text, xml and html formats |
|
Additional style sheets available for PDF |
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes