1. HL7 2.X Conformance Tutorial
January 2001
Ioana Singureanu, Eversolve
Mary Ann Juurlink, Killdara

2. Speakers Ioana Singureanu, CEO Eversolve ioana@eversolve.com
Mary Ann Juurlink, Healthcare Product Architect, Killdara

3. Kathy Blyler, Kathryn.Blyler@SMED.COM
Also thanks to
Kathy Blyler,
Bas van Poppel,

4. Part 1 : Conformance Concepts
Overview of HL7 2.x Conformance
Conformance Concepts
Use case derived message profiles
Ioana Singureanu
Sample Conformance documentation
Mary Ann Juurlink

5. Part 2: Hands-on tutorial
Hands-on message profiling exercise
Real-life scenarios
See the specification and tool in action !

6. Part 1 : Conformance Concepts
Overview of HL7 2.x Conformance
Conformance Concepts
Use case derived message profiles
Ioana Singureanu

7. The problem...
Interoperability standard for clinical application – uptake …
The standard combines the collective experience of many vendors
Multiple business requirement sets combined but not enough specificity for any given implementation: optionality.
Optional message elements had encouraged standard uptake but created difficulties in establishing standard conformance
Z-segments, Z-triggers, optional fields and segments are all allowed by the standard.
LACK OF UNIFORM SEMANTICS

8. The solution... V3
V2.X
RIM
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)
Collective Experience
MDF
Common
Message
Type
Message
Type
equivalent
Requirements
Requirements
Message
Type
Message
Profile

9. Conformance SIG HL7 Conformance has two objectives:
Interoperability
Implementable message profiles
Certification
Conformance Statement
Informative Documentation
Specification for Message Profile Content
Tutorial - education
You are invited…

10. Glossary… Message Profile Conformant Message Profile
Message profile id
Conformance Statement
Compatibility
Consistency
Registration
Certification
Validation

11. Message Profile
Message specification indicating a precise, unambiguous use of message constructs (segments, fields, data types) for exchanging information based on a messaging standard.
A message specification where “optional” are disallowed and repeatable constructs will be bound by maximum cardinality specifications.
developed by vendors to describe their applications’ interoperability
developed by healthcare providers to describe their interoperability needs.

12. Message Profiles specify…
Use Case Model (UML) and Vocabulary (field semantics, code sets, user-defined value sets)
Static message profile
Message,segment, field, data type
Dynamic interaction
Initiating message, response message

13. Conceptual Overview Message Profile = Static Profile + Dynamic Profile
Initiating Message
Response Message
Critical Care Unit
A/D/T System
Initiating Message
Clinical Data Repository

14. Static Message Profile
HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)
ADT^A01
...
...
MSH
EVN
PID
NK1
PV1
PV2
OBX
AL1
Segments/Segment Groups:
- Cardinality (min, max)
Message Profile
HL7 Message Structure
MSH
EVN
PID
...
NK1
NK1
NK1
NK1
NK1
PV1
Fields/Components:
- Field Usage (Optionality)
(R, RE, C, CE, X)
- Cardinality (max repeats)
- Value Sets/Coding system
- Descriptions
PV2
OBX
AL1
...

15. Message Profile Specification
HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)

16. Segment Profile Specification
Specification of Field Usage and Cardinality

17. Field/Component Profile Specification
Field Descriptions
In cases where HL7 2.x fields descriptions are unclear or ambiguous, supply a more precise semantic definition.
User defined tables
For each HL7 user defined table used, define set of valid values
By agreement between AWG members, HL7 user defined tables evolve into AWG pre-defined tables
Coding Systems
For each coded entry (CE) type field used, identify the specific coding system used.
Repeat cardinality
For repeating fields, define the maximum number of repeats
Field Descriptions
In cases where HL7 2.2 fields descriptions are unclear or ambiguous, supply a more precise semantic definition.

18. Field/Component Profile Specification
Vendor defined tables:
HL7 2.2 definition of PID-26 refers to Table #0171 which is undefined
HL7 suggests using ISO-3166
ISO 3166 has 3 different coding schemes - Alpha-2, Alpha-3, Numeric
A vendor/provider may choose ISO Alpha-3

19. Message Profile Hierarchy
v2_2(4)
Version
static-profile(1)
ADT(3)
O01(92)
A02 (2)
1(1)
NEW(1)
CANCEL(4)...
DIAG(1)
ORM(21)
NULL (0)
CANCEL(4) ...
DIET(2) ...
ORU(23)
R01(112)
LAB(1)
Profile Type
Message Type
Trigger Event
Structure
Use Model
Data Version
Registration Authority
HL7(1)
Organization
NULL (0)
NULL (0)
DEVICE(2)

20. Clinical Data Repository
Dynamic Interaction
Receiver Responsibility
MSH-15,16
Critical Care Unit
HIS/CIS
A/D/T System
Accept + App ACK
1. this is not a replacement for the process
2. we will be looking into new tools as they become available!
No ACK
Clinical Data Repository
Accept Ack
Order Filling Application

21. Message Profile Summary
Well-defined process for developing Message Profiles.
A Message Profile is a pre-negotiated agreement:
Static (data contents)
Dynamic (application interaction)
Registered by a unique identifier.

22. Message Profiles are used for…
Describing the content of inbound and outbound interfaces
Conformance statement
Certifying conformance
Validating messages
Simplifying interoperability
Not plug-and-play but… close

23. Sample Application Use Case
HIS
System
Radiology
System
Application Use Case
Patient
Management
Oncology
System
Sender
Receivers
Message Profile
Discharge
Admission
Transfer
{ }
{ }
{ }

24. Message Profiles are HL7 Conformant
A message profile which meets the HL7 standard requirements: all the required segments and fields are specified and all fields are using the appropriated HL7 data types as specified in the Chapter 2 of the HL7 standard
Only conformant profiles will be registered

25. HL7 Message Profile Identification
A unique identifier is assigned to a message profile submitted by a vendor or a healthcare provider
Assigned when the profile is registered with HL7 (Registration tool)
ASN.1 Generated by the message profile registration tool (HL7 provided to members)
Unique – OID – ASN.1(American Symbolic Notation) Object Identifier
Conformance SIG

26. OID…
OID root for Registered Conformance Profiles is:
ISO 16
840
HL7
Profile
Samples: …

27. Purpose of OID Unique identifier Registration
For cataloging message profiles registered by HL7
Used to specify the conformance statement of an application
References to OIDs

28. Conformance Statement
A document describing the HL7 interoperability characteristics as a use case model (UML) of an application and the message profiles implemented by that application.
Describes overall interoperability requirements along with the message profiles.
Basis for compliance certification

29. Application Conformance Statement
Message Profile
Registry
Oncology System
Conformance Statement
Use Case Model
Reference to…
{ }
{ }
{ }
{ }
Radiology System
Conformance Statement
Use Case Model
{ }
{ }
{ }
{ }
ASN.1 identifiers
Application Conformance Statement

30. Compatibility
Relationship between an outbound and an inbound message profile such that, despite differences, they can interoperate
Outbound message profile will be richer in content than an inbound profile.

31. ADT Message Profile Compatibility Example
Hospital Registration System (producer)
Radiology system
(receiver)
Oncology system
(receiver)
Nursing System
(receiver)

32. Consistency
Characteristic of all message profile specifications registered with HL7.
XML documents following a pre-defined DTD
Consistent documentation of message profiles will ensure that vendors and providers will be able to easily integrate applications.
Encourages reuse, comparison, differences
Simplifies interoperability

33. Application Role
The set of messages (message types) an application can send or received as part of its operation. Applications with similar interoperability needs are expected to use the same application profile.
Part of HL7 Version 3

34. Registration
A conformant message profile document will be registered with HL7 and be granted a unique message profile identifier.

35. Certification
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

36. Verification
The process by which a message instance (one message) is verified against the message profile on which it is based.

37. <XML>Considerations </XML>
XML Message
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.
Message = document
Version 2.XML specification from XML Sig (informative -> normative)

38. Conformance Benefits Consistent documentation Reuse of specification
Convergence on use cases
Lower cost of integration
Tool for comparing specifications
Similar to Version 3
Conformance SIG is developing Implementation guide
Chaos -> order

39. Conformance Support in the HL7 Standard
Version 3
At the core of the Message Development Process
Chapter 8 of MDF
Implementation Guide
Version 2.4, 2.5
MSH:21
Profile identifier
OID data type for ASN.1 identifiers
Conformance Chapter
Implementation Guide

40. Use case derived message profiles
Overview of HL7 2.x Conformance
Conformance Concepts
Use case derived message profiles
Sample Conformance documentation

41. Use Case Analysis UML Use Case Analysis Use Case Models
Language for describing requirements
Use Case Analysis
Use Case Models
Conceptual Interoperability Model
Expressed in the user’s terms
Information Model

42. Use Case derived Message Profiles
Specification for Message Profile Content
See the HL7 web site
Use cases, static profile, dynamic specification, profile identifiers
Allows clinical site and application vendors to specify their standard conformance
XML DTD/schemas for describing profiles
Profiling tool

43. Vendor Message Profiles
Conformance Statements
Contract between vendor and customers
It will enable clinical sites to make better purchasing decisions and clearly evaluate the capabilities of various software products.
Unambiguous, registered, backed by design and analysis

44. Site Message Profiles Supports specific needs
Required of third-party application vendors
RFP
Simplifies introduction/acquisition of new applications

45. HL7 Registry of Profiles
Search/browse
Unique profile identifiers
Consistent Profile Documentation
DTD/Schema representation of the profile
Indicates who is using a profile
Version 3 application roles

46. (for a given application)
Version 3 Deliverables
(for a given domain)
Version 3 Conformance
(for a given application)
Actors
Profiled App
Domain
Use Case
Analogous to
V2.x Profiling
Use Case
Model
Leaf-level
Use Cases
Role1
Sends
Receives
Role1
Sends
Receives
Sends
Receives
Application
Profile
Role1
Sends
Receives
Role1
Sends
Receives
Static Message
Structures
Interaction
Model
HMD

47. Sample Conformance documentation Mary Ann Juurlink
Overview of HL7 2.x Conformance
Conformance Concepts
Use case derived message profiles
Ioana Singureanu
Sample Conformance documentation
Mary Ann Juurlink

48. The Goal
To enable healthcare organizations to better communicate with their partners by sharing data electronically
To facilitate Healthcare integration efficiently and cost effectively
To use and promote open systems and standards
Lets start by stating the obvious, looking at the goal from a birds eye view, 3000 feet in the air.
The goals
The technology is in place
the HL7 standard is to discussing Conformance as conformance is becoming a hot topic in most working groups or at least a concern. We just aren’t quite sure what conformance is what it means to be conformant and just how to go about it. Well we hope to change this in this tutorial and in general by encouraging all vendors to profile their messages and register them so that they can be reused.
Generally speaking the use of open systems and standards should be encouraged as an accepted norm – not being the value added to a product but the utility of a product is the value added.

49. Existing Infrastructure
Hospital Registration System
Clinical information system
support messaging (VPN)
no support for secure communication (Internet)
Remote Lab system
Remote Physician’s Office
cannot send/receive messages easily
Existing Infrastructure

50. How do we achieve the goal?
By developing profiles for applications
By encouraging vendors to create their own profiles and register them with HL7
By creating a transition path (V2.x -> V3.0) based on conformance profile development
How do we achieve our goals
To better communicate
To integrate efficiently and cost effectively
To use and promote open systems and standards
considering the existing infrastructure
Documenting messaging which are already in use
As we have seen in Ioana’s slide 8 “The Solution” a v3 message = v2.x profile
Define
XML- XML (eXtensible Markup Language). XML is a new technology that uses Document Type Definition (DTD). The DTD portion of an XML document tells the recipient what kind of information is found in the document.
PKI - PKI has been recognized by HIPAA and has been broadly adopted by national healthcare organizations. (encrypted, signed digitally (X.509), using PKI Entrust™ )
HL7
imitates the process of developing v3 messages from HMD
At this point we will be talking about HL7 and how it fits into our goals
V2.x -> messages + profiles (disambiguates messages)
V3.0 -> RIM -> HMD -> messages (initial high level analysis)
V2.x as it is now has no formal design process and is not scalable.
V2.x implies, indicates, and suggests…..but is not formally documented

51. Message Profiling Specification
Use case model
Vocabulary
Coding
Value sets
Field semantics
Static Definition of an HL7 v2.x message
Message Level Profile
Segment Level Profile
Field Level Profile
Dynamic Definition of HL7 v2.x message
Interaction Model
V2.x as it is now
has no formal design process and is not scalable.
implies, indicates, and suggests…..but is not formally documented
This is the outline of the Specification Tool developed by the Conformance SIG. It has been balloted in the Spring of 2000 and updated / posted to the Conformance section of the HL7 web site. This is considered an informative document.
Initially thinking about the data to be exchanged
Interactions?
User requirements?
Challenge comes in with semantics (vocabulary)
Profiles encourage the definition of fields
Requirements are the basis or starting point for profiles., starting point?
what kind of information do I have to send / receive?
Send a lot, authority in area i.e. registration (export demographics)
Receiving end, what is partner expecting?
How do we express requirements?
V2.x use cases
V3 storyboards
By defining use cases we let others know operability therefore we increase the possibility of interoperability

52. Register a Patient ADT^A04
Scenario
40 year old female
Diabetes
Community hospital
Arrives by ambulance
Message Description
A registration event (ADT^A04) signals that a patient has arrived or checked in but is not assigned a bed.
Let’s apply this Specification Tool to the ADT^A04 message.
Scenario, natural language. This is one scenario of many, could arrive with a heart condition and the registration system would do the same thing.
Person with preexisting condition presents a number of complaints, diagnosis of diabetes and arrives in emerg. There is a protocol which is followed. We don’t yet know if the patient is to be admitted yet we need a minimum amount of information, and tracking of what is to be done with the patient for this visit.
Questions:
What do other applications need to know?
Patient demographics (patient ID, patient name)
Next of Kin
Admit Vist Info (patient class – in this case its an emergency class)
Allergy Info (ID transaction, or Allergy code – referencing some external coding system
Who needs to be included in the broadcast? Interested parties could be lab, primary physician, billing.
Essentially the trigger event states what happened and this is the information you want to exchange.

53. Use Case Actors Hospital registration System Remote Lab System
Is responsible for notifying all appropriate systems
Remote Lab System
Receives the messages and sends results
Remote Physicians Office
Receives the message

54. Use Case Model +routes message FiveSight +sends message
+receives message
Patient Registration
Care Data
Intrinsiq
A Use Case model represents the functionality of the systems from beginning to end. Here we see how all these actors come together to play their role when registering a patient. Using the XML 2000 demo again we see CDS sending the registration, Five Sight routing the messages, and Intrinsiq and Killdara receiving the messages.
Peter what is the difference between system and actor?
ADT^A04
Systems
+receives message
Killdara

55. Use Case Description Preconditions
The patient is ready for clinical attention and demographic information is supplied
Flow of events
The patient is registered and the appropriate system is notified
Post Conditions
The appropriate system has been notified
This may seem very over simplified however this simplicity and clarity distinguishes
the beginning and end of a functionality
messages
So the wording and sequencing is important.

56. Dynamic Interaction AcceptNever, Application Never Sequence Diagram
CDS sending v2.x XML
Where necessary translation to ASCII ER7 encoding (pipes and hats), i.e. remote site
AccNe AppNe
not necessary if there is a reliable/robust transport mechanism, which guarantees message delivery
AccAL – i.e. unsolicited acknowledgement message. Signifies that the receiver got the message only. Redundant if using AppAL.
AppAL – ORR^O02 order response message, application level
Receiver responsibility
AcceptNever, Application Never

57. Static Definition Message Level Profile
ADT^A04 Cardinality Message Description
MSH [1,1] Message Header
EVN [1,1] Event Type
PID [1,1] Patient Demographics
[{ NK1 }] [0,+] Next of Kin
PV1 [1,1] Admit Visit Info
PV2 [1,1] More Admit Visit Info
[{ AL1 }] [0,+] Allergy Info
Segment Level Profile
PID (1) – Patient Demographics
SEQ DT R/O RP/# ITEM# TBL# ELEMENT NAME
SI RE SetID – Patient ID
CK RE Patient External ID
CM R Y Patient Internal ID
ST RE Y Alternate Patient ID
PN R Patient Name
ST RE Mother’s Maiden ..
TS RE Date Of Birth
ID RE Sex
PN RE Y Alias
ID RE Race
AD RE Y/ Address
Field Level Profile
Patient Internal ID (00106)
Components: <patient ID (NM)> ^ <check digit (NM)> ^ <check digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type (ID)>
Patient Name (00108)
Components: <family name> ^ <given name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^ <degree (e.g., MD)>
Name is standard format described in Chapter 2, HL7 Standard.
Blank
* (1 or many)
? (0 or 1)
+ (0 or many)

58. ADT^A04 XML Conformance Profile produced using the Message Work Bench report XML Spec
<Field Name="Patient ID (Internal ID) " Description="" Optionality="R" Repeatable="Y" Sequence="3" Primitive="T" Datatype="CM" Length="20" QuantLo="1" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field>
<Field Name="Alternate Patient ID " Description="" Optionality="NS" Repeatable="N" Sequence="4" Primitive="T" Datatype="ST" Length="12" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field>
<Field Name="Patient Name" Description="" Optionality="R" Repeatable="N" Sequence="5" Primitive="F" Datatype="PN" Length="48" QuantLo="1" QuantHi="0"><Component Name="family name" Description="" Optionality="O" Repeatable="N" Sequence="1" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component> <Component Name="given name" Description="" Optionality="O" Repeatable="N" Sequence="2" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component>

59. HL7 Conformance Profile DTD V2.X
This is the result of associating the dtd with the ADT^A04 Conformance Profile
All profiles registering with HL7 must be validated against this dtd
One dtd per version
<!-- PID - Patient Identification section -->
<!ELEMENT PID (PID.3+, PID.5, PID.27* )>
<!ELEMENT PID.3 (#PCDATA)>
<!ELEMENT PID.5 (PID.5.1?, PID.5.2?, PID.5.3?, PID.5.4?, PID.5.5?, PID.5.6? )>
<!ELEMENT PID.5.1 (#PCDATA)>
<!ELEMENT PID.5.2 (#PCDATA)>
<!ELEMENT PID.5.3 (#PCDATA)>
<!ELEMENT PID.5.4 (#PCDATA)>
<!ELEMENT PID.5.5 (#PCDATA)>
<!ELEMENT PID.5.6 (#PCDATA)>
<!ELEMENT PID.27 (#PCDATA)>
1 dtd / version
Rules and regulations
The Conformance Profile will be validated against the Conformance dtd for Registration purposes. This is an excerpt.

60. The Most Common ADT HL7 Message Profiles
ADTA01_AdmitPatient
ADTA02_TransferPatient ADTA03_DischargePatient ADTA04_RegisterPatient ADTA05_PreadmitPatient ADTA08_UpdatePatientInfo ADTA11_CancelAdmit
See list for ADT fields, common segments, and datatypes.

61. The Most Common Order/Result HL7 Message Profiles
ORMO01_NewDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderAccepted ORRO02_UnableToAcceptDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelled ORMO01_CancelDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelledAsRequested ORRO02_UnableToCancelDiagnosticStudyOrder

62. HL7 V3 Message Development Lifecycle
Analysis
Design
Application
Messaging
Message Types
for use with
XML, ER7, etc
(MET)
Requirements
Analysis
Use Case
Model
(UCM)
Domain
Analysis
Information Model & Vocabulary
(RIM)
Interaction
Design
Model
(IM)
Message
Design
Hierarchical Message Descriptions
(HMD)
Documents
Document Types for HL7 PRA
(DTD)
Medical logic
Variable
definition for
Arden syntax
(AVD)
TYPE MPSLOC CONTAINS {
id[id].TYPE IID
nm[name].TYPE ST
ad[addr].TYPE XAD
ph[phon].TYPE XTN _address [emlAdr].TYPE XTN }
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
<!ENTITY %DT_MPSLOC “MPSLOC.id, MPSLOC.name?, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.emlAdr?">
data: location_of_action := READ LAST MPSLOC ;
‘ {patient location}
This diagram shows the four essential development steps for Version 3 standards, and the application of the resulting models to specific standards.
C Code c Code a art b blue c color
Reference Model Repository

63. Deliverables
Some form of the “Technical Committee Documentation Template”
Domain interaction model
Leaf level interaction model
Common message types (HMD)
So now what do we do with all of this?
How to we apply our specific user requirement?

64. Starting point for Conformance Profiling
Once you have the user requirements, of course! 

65. Hierarchical Message Definition
Information Model Mapping
Classes and attributes of the R-MIM, describes a “walk” through.
Message Element
Describes elements and types, set up as a hierarchy
General constraints
Describes specific constraints for the message element defined in the row

66. Constraints based on application requirements

67. Message Profiling Specification for Version 3
Use case model
Vocabulary
Coding
Value sets
Field semantics
Static Definition of an HL7 V3 message
Message Level Profile
Segment Level Profile
Field Level Profile
Dynamic Definition of HL7 3 message
Interaction Model – application role
Profiling process same for V2 or V3
We need the implementation of the standard to meet application requirements not the reverse!
Think
Ask
Research
Functional analysis refinement
Document
Vendors to document profiles
Register with HL7
Promote reuse

68. Version 3 vs. Version 2.X V3 V2.X Analysis, Design Collective
i.e
RIM
Interaction model
Collective
Experience
HMD
Message
Common
Specific
overview
Common message type in HMD equates to V2
V3 message type more specific, more refined
Union message???
disambiguate
Profile
Profile

69. Benefits of Message Profiling
Conformance statement
Describes a standard implementation by coupling events, data elements and messages
Improves clarity and precision
Profiles may be registered with HL7
Approaches plug and play
Conformance testing
Messages can be validated against the message profile
As we have heard from Ioana’s presentation a conformance statement is:
A document describing HL7 overall interoperability charateristecs (overall use case)
Message profiles
Sooo part of a conformance statement is a message profile
Conformance testing – validating of cardinality, min, max, repeating
profiles may be reused by vendors with similar needs

70. ROI Benefits of Hl7 Conformance
Reduces the overhead of integrating applications
EFFICIENCY
Able to meet the needs of the clinicians for access to information, when and where they need it
QUALITY OF COMMUNICATION
Clinical sites can evolve yet maintain their infrastructure
SAVINGS
Efficiency
Provides basis for consistent mapping to HL7 messages
Provides basis for future mappings
Supports linkage to open healthcare standards
Disambiguates the message
Quality
Savings
Maintains the integrity of existing systems.
We consider the Specification Tool as a Transitional Tool from v2.x – v3

71. Conformance Tool Available!
The Messaging Workbench tool is available free of charge
It is open source
It is supported within the VA for the foreseeable future

72. Contacts
We in the Conformance sig are interested in your feedback and suggestions for improvement of the tool
The Conformance sig list server is a good source for general information
For conformance tool information:

73. Q&A