IHE International

Document Sample
IHE International Powered By Docstoc
					Integrating the Healthcare Enterprise




IHE ITI Technical Framework
Supplement 2008-2009




Sharing Value Sets
(SVS)


Public Comment Version 1.0
Comments due July 9, 2008

Foreword
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration
of the information systems that support modern healthcare institutions. Its fundamental objective
is to ensure that in the care of patients all required information for medical decisions is both
correct and available to healthcare professionals. The IHE initiative is both a process and a
forum for encouraging integration efforts. It defines a technical framework for the
implementation of established messaging standards to achieve specific clinical goals. It includes
a rigorous testing process for the implementation of this framework. And it organizes
educational sessions and exhibits at major meetings of medical professionals to demonstrate the
benefits of this framework and encourage its adoption by industry and users.
The approach employed in the IHE initiative is not to define new integration standards, but rather
to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in their
respective domains in an integrated manner, defining configuration choices when necessary.
IHE maintain formal relationships with several standards bodies including HL7, DICOM and
refers recommendations to them when clarifications or extensions to existing standards are
necessary.
This initiative has numerous sponsors and supporting organizations in different medical specialty
domains and geographical regions. In North America the primary sponsors are the Healthcare
Information and Management Systems Society (HIMSS) and the Radiological Society of North
America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a
large coalition of organizations including the European Association of Radiology (EAR) and
European Congress of Radiologists (ECR), the Coordination Committee of the Radiological and
Electromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS
Association, Groupement pour la Modernisation du Système d'Information Hospitalier
(GMSIH), Société Francaise de Radiologie (SFR), Società Italiana di Radiologia Medica
(SIRM), the European Institute for health Records (EuroRec), and the European Society of
Cardiology (ESC). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and
Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDIS-DC; cooperating
organizations include the Japan Industries Association of Radiological Systems (JIRA), the
Japan Association of Healthcare Information Systems Industry (JAHIS), Japan Radiological
Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan Association of
Medical Informatics (JAMI). Other organizations representing healthcare professionals are
invited to join in the expansion of the IHE process across disciplinary and geographic
boundaries.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology,
Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve
integration goals that promote appropriate sharing of medical information to support optimal
patient care. It is expanded annually, after a period of public review, and maintained regularly
through the identification and correction of errata. The current version for these Technical
Frameworks may be found at www.ihe.net/Technical_Framework.
The IHE Technical Framework identifies a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,
standards-based transactions. It describes this body of transactions in progressively greater
depth. The volume I provides a high-level view of IHE functionality, showing the transactions
organized into functional units called Integration Profiles that highlight their capacity to address
specific clinical needs. The subsequent volumes provide detailed technical descriptions of each
IHE transaction.
This supplement to the IHE ITI Technical Framework is submitted for Public Comment
between June 6 2008 and July 9 2008, per the schedule announced in December 2007.
Comments shall be submitted before July 9 2008 to:
http://forums.rsna.org under the “IHE” forum
Select the “ITI Profiles for Public Review” sub-forum.

The IHE ITI Technical Committee will address these comments and publish the Trial
Implementation version in August 2008.
Table of Contents
1      Foreword        1
2      Introduction 4
2.1    Open Issues and Questions 4
2.2    Closed Issues 4
2.3    Future Considerations 4
3      Profile Abstract       5
4      Glossary        6
Volume I – Integration Profiles      9
History of Annual Changes 9
2.2.Y Sharing Value Set Integration Profile (SVS) 9
Y Sharing Value Sets Integration Profile (SVS)      9
Y.1 Business Value       PAGEREF _Toc200461498 \h          13
Y.2 Assumptions and background information            PAGEREF _Toc200461499 \h      13
Y.2.1 Value Set Unique ID and Value Set Version       PAGEREF _Toc200461500 \h      14
Y.3 Use Cases PAGEREF _Toc200461501 \h              16
Y.3.1 Distributing a consistent nomenclature in an XDS Affinity Domain      PAGEREF
_Toc200461502 \h        16
Y.3.2 Updating terminology codes for a medical and billing across systems        PAGEREF
_Toc200461503 \h        16
Y.3.3 HCPs Nomenclature Tables‘ Update         PAGEREF _Toc200461504 \h        18
Y.3.4 Consistent Encoding Terms for anatomical regions in imaging           PAGEREF
_Toc200461505 \h        19
Y.3.5 Modification of a protocol code for a mammogram exam           PAGEREF
_Toc200461506 \h        21
Y.4 Actors/ Transactions         PAGEREF _Toc200461507 \h         23
Y.5 SVS Integration Profile Options PAGEREF _Toc200461508 \h              24
Y.6 SVS Process Flow             PAGEREF _Toc200461509 \h         24
Y.7 SVS Security Considerations         PAGEREF _Toc200461510 \h          25
<Appendix A> Actor Summary Definitions         PAGEREF _Toc200461511 \h        26
<Appendix B> Transaction Summary Definitions          PAGEREF _Toc200461512 \h      26
Volume 2 - Transactions          PAGEREF _Toc200461513 \h         27
3.XX Retrieve Value Set          PAGEREF _Toc200461514 \h         27
3.XX.1 Scope PAGEREF _Toc200461515 \h               27
3.XX.2 Use case roles PAGEREF _Toc200461516 \h             27
3.XX.3 Referenced Standard PAGEREF _Toc200461517 \h               27
3.XX.4 Interaction Diagram       PAGEREF _Toc200461518 \h         28
3.XX.5 Protocol Requirements            PAGEREF _Toc200461519 \h          30
3.XX.6 Security Requirements            PAGEREF _Toc200461520 \h          33
Introduction
The Sharing Value Sets (SVS) profile provides a means through which healthcare systems that
produce clinical or administrative data, such as diagnostic imaging equipment, laboratory
reporting systems, primary care physician office EMR systems, or national healthcare record
systems, can receive a common, shared nomenclature managed in a centralized fashion. Such
shared nomenclatures are essential to semantic interoperability, for example as lists of orderable
or billable procedures, types of healthcare facilities, or classifications of healthcare providers.
This profile describes a mechanism of retrieving a Value Set from a Value Set Repository by a
Value Set Consumer. A single Value Set Repository can be accessed by many Value Set
Consumers, establishing a domain for consistent and uniform nomenclature. It supports
automated loading of Value Sets in the Value Set Consumers, reducing the burden of manual
configuration, and allowing a single application design to operate in a variety of different
domains (e.g. international).
Open Issues and Questions
A mechanism will have to be set so that the user will know the expiration date since some Value
Sets are time-sensitive.
Should each Value Set have a version? This profile assumes that each Value Set present in the
Value Set Repository must have a version attribute.
There must be a version present for the Value Set. If there is no version, then the Value Set will
not be present in the Repository. The method of versioning itself is out of the scope of this
profile. The version is optional on the Retrieve request, and it is required on the Retrieve
response. This is a decision on an issue that is out of scope since this profile does not define how
the Value Sets get into the Repository.
Closed Issues
The Value Set Retrieval mechanism is modeled after the Retrieve Document Set transaction in
XDS.b. As the SVS profile is developing, a similar structure as XDS could be envisioned,
eventually having a Value Set Registry. The standard ebXML RS (Registry Service) will not be
used.
The mechanism of use within a healthcare facility versus the one used on a larger scale, such as
using a National Terminology Server was discussed. A possible limiting factor in this case is the
presence of Web Services across and within the healthcare enterprises. The committee has
estimated that there should be no difference between the two settings, and that the web services
burden is on the terminology server side, regardless of the mechanism used.
The web services specifications are used according to Appendix V synchronous services
interactions. If there is a change in Appendix V, then the basis of this profile will need to be re-
assessed. This profile will not develop independently; it will defer to other mechanisms used in
IHE. The asynchronous mode is not part of this profile.
The definitions present in the Glossary are based on the HL7 Vocabulary and the ISO
definitions. Whenever there is a double definition, the HL7 Vocabulary model definition will
take precedence.
Future Considerations
The SVS Profile does not contain a Value Set Registry. The existence of a Registry would help
refining the search and the use in general of the SVS profile (versioning, text searching, etc).
This profile is not addressing mapping a Value Set onto an existing or internal Value Set or Code
System at this time and may be addressed in future text.
The language will not be a parameter in the Value Set retrieve transaction. The language hence
forth will be referred to locale specific name. In a bilingual country, for example, the locale
specific name can be a very useful feature. Since the name of the description will have to be
pushed to a separate layer and the language will have to be bound to another layer, this is
considered a separate look-up process, and it is not part of the XML binding. This functionality
can be addressed via the Registry, and the Registry is not part of this year‘s profile‘s scope. The
local specific name cannot be part of the Value Set.
 The use portable media to exchange Value Sets will be considered in the future.
The white paper Publish and Subscribe that is under development this year could provide a
solution to the notification problem. The NAV profile is not used since the update of a Value
Set does not happen that often. The profile Publish and subscribe is better for solving the
versioning problem, and the NAV profile is better to alert the users about the availability of a
new Value Set. When a Registry will be put into place, these issues could be addressed. The
mechanism proposed is a human notification (send an email or telephone).
The versioning abilities will be addressed in the next cycle. The method of update will also be
discussed when the standard CTS2 will become available. Two possible update modes were
discussed: either importing a whole new Value Set or having an incremental change from one
version to the other. The importance of having a differential update is of importance when the
Value Set source publishes updates in that way, for example CTP codes. This might be an
implementation issue.
Since a Value Set Registry is not used, the following topics are considered for the future:
The mapping a Value Set onto an existing or internal Value Set or Code System.
A way of expressing the ontology or classification within a Vocabulary (Concept) Domain
The obsolete terms within a version will have to be handled in the future (this issue is of interest
for new implementations).
There is a possibility of using the developing standard CTS2 in conjunction with the SVS profile.
Profile Abstract
Add the following to section 3 Profile Abstract:
The Sharing Value Sets (SVS) profile provides a means through which healthcare systems that
produce clinical or administrative data, such as diagnostic imaging equipment, laboratory
reporting systems, primary care physician office EMR systems, or national healthcare record
systems, can receive a common, shared nomenclature managed in a centralized fashion. Such
shared nomenclatures are essential to semantic interoperability, for example as lists of orderable
or billable procedures, types of healthcare facilities, or classifications of healthcare providers.
This profile describes a mechanism of retrieving a Resolved Value Set from a Value Set
Repository by a Value Set Consumer. A single Value Set Repository can be accessed by many
Value Set Consumers, establishing a domain for consistent and uniform nomenclature. It
supports automated loading of Value Sets in the Value Set Consumers, reducing the burden of
manual configuration, and allowing a single application design to operate in a variety of different
domains (e.g. international).
Glossary
Add the following to section ITI TF-1: Glossary:
Classification - A terminology system in which fine-grain concepts are aggregated into broader
categories, typically for the purpose of comparison. Example: International Classification of
Disease
Code System - A terminology system in which concepts (designations and meanings) are
assigned codes, i.e. character strings for use in information exchange. Concept codes within a
code system should not change meaning, as that would prevent semantic interoperability with
historic data. Code systems might vary in size and complexity from a simple code/value table,
such as HL7 Administrative Gender, to a complex reference terminology containing thousands
of terms and relationships. Examples are: LOINC, SNOMED-CT, ICD-10, ISO 639 Language
Codes.
Concept - A general idea derived or inferred from specific instances or occurrences. It is defined
as something formed in the mind; a thought or notion. A concept defines a unitary mental
representation of a real or abstract thing; an atomic unit of thought. A concept should be unique
in a given terminology system and may have synonyms in terms of representation. A concept
may also be a primitive (single unit of thought) or a compositional term (a grouping of concepts
together).
Coded Concept – A concept has a unique identifier within a Code System. A coded concept
might be characterized by zero or more Concept properties. A coded concept has a code within
the Code System which uniquely names the class or ―concept‖ within the context of the defining
Code System. A coded concept also has a status which indicates the current status of the Coded
Concept within the Code System. Once defined, the meaning of a coded concept may not
change. Existing coded concepts may be retired and new coded concepts may be added, but once
defined, the meaning of a coded concept must remain static.
Concept Code – A code that uniquely identifies a class or concept within the context of a code
system.
Concept Descriptor - represents any kind of concept usually by giving a code defined in a code
system. A concept descriptor can contain the original text or phrase that served as the basis of the
coding and one or more translations into different coding systems. A concept descriptor can also
contain qualifiers to describe, e.g., the concept of a "left foot" as a post-coordinated term built
from the primary code "FOOT" and the qualifier "LEFT". In exceptional cases, the concept
descriptor need not contain a code but only the original text describing that concept
CTS – Common Terminology Services – the HL7 Common Terminology Services (CTS)
specification was developed as an alternative to a common data structure. Instead of specifying
what an external terminology must look like, HL7 has chosen to identify the common functional
characteristics that an external terminology must be able to provide. The HL7 Common
Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can
be used by HL7 Version 3 applications when accessing terminological content.
Element – a section of a document defined by start and end tags (or an empty tag), including any
associated content.
HCP – Health Care Professional
HIE – Health Information Exchange
Terminology System, or Nomenclature – an organized set of concepts (e.g., represented in
tables, lists, and rules of identity attribution), which are governed by a specific authority and
which serve a given discipline. A Terminology System may be a simple list of concepts, or it
may include a complete ontology for the domain, and may include a grammar for composing
new complex concepts. A Terminology System also generally connotes a Code System for
representing its concepts for information exchange.
OID - object identifier - is an identifier used to name an object. Structurally, an OID consists of
a node in a hierarchically-assigned namespace. Successive numbers of the nodes, starting at the
root of the tree, identify each node in the tree. Designers set up new nodes by registering them
under the node's registration authority.
Ontology - is a representation of a set of concepts within a HYPERLINK
"http://en.wikipedia.org/wiki/Domain_of_discourse"         domain and the relationships between
those concepts. It is used to HYPERLINK
"http://en.wikipedia.org/wiki/Reasoning"        reason about the properties of that domain, and
may be used to define the domain. Common components of ontologies include:
HYPERLINK "http://en.wikipedia.org/wiki/Class"           classes , HYPERLINK
"http://en.wikipedia.org/wiki/Attribute_(computing)"        attributes , HYPERLINK
"http://en.wikipedia.org/wiki/Relation_(mathematics)"         relations , function terms,
restrictions, rules, HYPERLINK "http://en.wikipedia.org/wiki/Axiom"              axiom , and
HYPERLINK "http://en.wikipedia.org/wiki/Event_(philosophy)"             events .
Terminology is the study of terms and their use — of HYPERLINK
"http://en.wikipedia.org/wiki/Word"         words and HYPERLINK
"http://en.wikipedia.org/wiki/Compound_word"           compound words that are used in specific
contexts. Terminology also denotes a more formal discipline which systematically studies the
labeling or designating of HYPERLINK "http://en.wikipedia.org/wiki/Concept"               concepts
particular to one or more subject fields or domains of human activity, through research and
analysis of terms in context, for the purpose of documenting and promoting correct usage. This
study can be limited to one language or can cover more than one language at the same time.
Value Set – A uniquely identifiable set of valid concept representations where any concept
representation can be tested to determine whether or not it is a member of the value set. A value
set may be a simple flat list of concept codes drawn from a single code system, or it might be an
unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code
systems. Also known as a list of valid concept codes. A Value Set may include a list of zero or
more Coded Concepts drawn from a single Code System. A Value Set can represent: all of the
Coded Concepts defined in exactly one Code System, a specified list of Coded Concepts that are
defined in exactly one Code System, or a set of Coded Concepts represented by another Value
Set. A Value Set can be extensional (meaning that it is comprised of an explicit enumerated set
of codes. The simplest case is when the Value Set consists of only one code. A Value Set can
also be intentional (meaning defined by a computable expression that can be resolved to an exact
list of codes. For example, an intentional value set definition might be defined as, ―All
SNOMED CT concepts that are children of the SNOMED CT concept ‗Diabetes Mellitus. A
Value Set may have zero or more identified versions. Each version may have different sets of
values during different effective times.
Resolved Value Set – a set of concept representations that were in effect at a specific time for a
particular version of a Value Set. See Value Set.
Vocabulary - All the words of a language. The sum of words used by, understood by, or at the
command of a particular person or group. A list of words and often phrases, usually arranged
alphabetically and defined or translated; a lexicon or glossary. A supply of expressive means; a
repertoire of communication
Vocabulary Domain – describes a ―conceptual space‖ from which the values of an attribute can
be drawn. A vocabulary domain serves as the link between an HL7 coded attribute and the set(s)
of valid concept codes for that attribute, representing an abstract conceptual space such as
"countries of the world", "the gender of a person used for administrative purposes", etc.
Each Vocabulary Domain has a unique name along with a description of the conceptual space
that it represents. Also see Concept Domain.
Vocabulary Domain Value Set - A Vocabulary Domain Value Set represents an association
between exactly one Vocabulary Domain and exactly one Value Set. Each association between a
Vocabulary Domain and a Value Set may apply in zero or one Application Contexts.
Volume I – Integration Profiles
This section describes the changes required in Volume I of the Technical Framework that result
form including this Integration Profile.
History of Annual Changes
Add the following bullet to the end of the bullet list in section 1.7
Added the Sharing Value Sets profile which provides a mechanism of retrieving a Value Set
from a Value Set Repository based on its OID.
Add the following section to Table 2-1 Integration Profiles Dependencies in section 2.1

Sharing Value Sets Audit Trail and Node Authentication The Value Set Repository must be
grouped with a secure node actor Required to manage audit trail of Value Sets sharing and node
authentication
Add the following section to section 2.2
2.2.Y Sharing Value Set Integration Profile (SVS)
The Sharing Value Sets (SVS) profile provides a means through which healthcare systems that
produce clinical or administrative data, such as diagnostic imaging equipment, laboratory
reporting systems, primary care physician office EMR systems, or national healthcare record
systems, can receive a common, shared nomenclature managed in a centralized fashion. Such
shared nomenclatures are essential to semantic interoperability, for example as lists of orderable
or billable procedures, types of healthcare facilities, or classifications of healthcare providers.
This profile describes a mechanism of retrieving a Value Set from a Value Set Repository by a
Value Set Consumer. A single Value Set Repository can be accessed by many Value Set
Consumers, establishing a domain for consistent and uniform nomenclature. It supports
automated loading of Value Sets in the Value Set Consumers, reducing the burden of manual
configuration, and allowing a single application design to operate in a variety of different
domains (e.g., international).

The section shall be added to Vol 1

Y Sharing Value Sets Integration Profile (SVS)
Y.1 Business Value
Data incompatibility issues are very costly to the healthcare delivery systems around the world.
A recent study has estimated possible savings in the US healthcare system of 78.8 billion dollars
annually if standardized data exchange were to be used [1].
Interoperability is considered a key factor for the implementation of pan-European eGovernment
services as well, a need that is given special attention by the Semantic Interoperability Centre
Europe, whose goal is to promote the reuse of syntactic and semantic assets needed for semantic
interoperability [2].
This profile means to address the semantic aspect, namely assuring a uniform, consistent and
centralized distribution of clinical and administrative data (nomenclature) used in for patient
care. Offering healthcare providers an easier access to a common, shared terminology would
encourage consistent encoding, and hence improve the initiative towards semantic
interoperability, resulting in improved overall patient care and cost savings.
The clinical data gathered can be further used by the clinicians and by public health, and
significant reduction of cost will be obtained as a result of timely reimbursements and less
rejection of the claims submitted.
Correct encoding is necessary to enable automated processing in addition to human interpretation
of ideas and concepts in the context of the electronic health record. Some of the benefits of
encoded information are:
The organization of information meant for human interpretation (classification of document
types and section headings, enable data filtering and exploitation, easier navigation to related
information)
Effective indexing and retrieval of information (specific types of records or data) [3].
The possibility of retrieving a centralized and uniform Value Set is important in order to achieve
these goals. Retrieving a new Value Set is needed when a new system is installed or a new Value
Set becomes upgraded.
Y.2 Assumptions and background information
A Value Set is a uniquely identifiable set of valid concept representations. A value set may be a
simple flat list of concept codes drawn from a single code system, or it might be constituted by a
hierarchical set of expressions drawn from multiple code systems. The simplest example of a
Value Set can be seen underneath:
Code Value Description      M Male         F Female       U Unspecified       Some possible
metadata defining a Value Set are:
Value Set Code
Value Set Name (Description)
Value Set Date Created
Value Set Date Revised
Value Set OID
Value Set Version

Y.2.1 Value Set Unique ID and Value Set Version
The author of a Value Set, whether a person or an institution, has a particular purpose (or
multiple purposes) in mind when is creating one. This purpose, or concept, must be uniquely
identified to allow various applications to recognize it regardless of the actual contents of the
Value Set. The retrieval of a Value Set, on the other hand, deals with a particular Resolved Value
Set.
There are two main ways to handle these two identifiable traits of a Value Set. The first way is to
assign a unique identifier for the Value Set concept, and also assign unique identifiers for each
Resolved Value Set. The second way is to use a combination of the Value Set concept unique
identifier, and a version which is unique only for this Value Set, and which is used to specify that
particular Resolved Value Set.
This profile uses the Value Set Unique ID and the Value Set Version attributes to allow for
flexible handling of either approach. If each Resolved Value Set has its own unique identifier,
then that identifier is conveyed using the Value Set Unique ID and the Value Set Version has no
meaning. If each resolved value set is identified by a combination of a concept ID and a version,
then the Value Set Unique ID shall contain the concept ID, and the Value Set Version shall
contain the version for this Resolved Value Set.
For ease of implementation, this profile requires all Value Sets in a Value Set Repository to have
both a Unique ID (using an ISO OID) and a Value Set Version. This ensures a uniform
representation of the Value Set metadata in the transactions, and abstracts the two major ways of
identifying a Resolved Value Set.
The Value Set to be retrieved has to have its own OID, and be a simple flat Code System, with
no parent-child relationships (no ontology).
OIDs can be registered by organizations like HL7 or CDC, or can be managed within an Affinity
Domain or the healthcare organization itself, while respecting the OID attribution rules.
The managing of OIDs (how does a Value Set obtain an OID) is out of the scope of this profile.
The Value Set Consumer can be used in conjunction with a Content Creator or a Content
Consumer. The coupling between the two is out of the scope of this profile.
The creation of a Value Set is out of scope of this profile. It will be addressed in a later cycle,
once the basic infrastructure of this profile is in place. For definition purposes, creating a Value
Set means the creation of a Value Set out of a Code System(s), or having the user proposing
values that s/he uses in their own system.
The complete process can be seen in Figure Y.2.1-1 below, included for clarity‘s sake:


        EMBED Visio.Drawing.11
Figure Y.2.1-1
The creation of a Value Set. The terms Terminology is used intentionally so that it can
differentiate between the entire Code Systems and Values Sets which are part of the Code
Systems. The focus of this profile is the area included between the thick lines.

A syntactic message or document structure, within which the nomenclature is to be used, is
assumed to be already in place. While the representation of structure is out of scope of this
profile, it must be recognized that it plays an important role in achieving semantic
interoperability. The focus of the profile is to distribute a generalized and uniform nomenclature
in order to populate the information model with the appropriate semantic content.

Y.3 Use Cases
The following use cases indicate how this profile might be used by various disciplines. The SVS
profile provides the infrastructure for all these use cases, yet not implementing directly any of
them. Actual discipline specific profiles that specify both the use of SVS and the rules for data
objects are expected in future-domain IHE-profiles.

Note: The tables present are used as examples only. IHE will not be responsible for updating
these tables according to the exiting nomenclature.
Y.3.1 Distributing a consistent nomenclature in an XDS Affinity Domain
A common nomenclature is required in an XDS Affinity Domain for metadata elements such as
classCode, confidentialityCode, eventCodeList, healthcareFacilityTypeCode,
practiceSettingCode, and typeCode.
Y.3.1.1 Current state
The nomenclature used in the Affinity Domain is being entered into systems manually.
Y.3.1.2 Desired state
Each vendor‘s application would retrieve the necessary Value Sets used in a XDS Affinity
Domain, saving them manual entry and improving accuracy.
Y.3.2 Updating terminology codes for a medical and billing across systems
In each country health care insurers process billions of claims for payment. Standardized coding
systems are essential for health insurance programs to ensure that these claims are processed in
an orderly and consistent manner.
In the United States, the HCPCS (Healthcare Common Procedure Coding System) Level II Code
Set is one of the standard code sets used for this purpose. The HCPCS is divided into two
principal subsystems, referred to as level I and level II.
The focus is on level I of the HCPCS, comprised of CPT (Current Procedural Terminology), a
numeric coding system maintained by the American Medical Association (AMA). The CPT is a
uniform coding system consisting of descriptive terms and identifying codes that are used
primarily to identify medical services and procedures performed by physicians and other health
care professionals (HCP) for billing public or private health insurance programs.
Regulations issued under the Health Insurance Portability and Accountability Act (HIPAA)
requires the use of CPT for reporting services to all payers for reimbursement.
Y.3.2.1 Current state
A patient is being referred by her PCP from a small healthcare facility A to an oncologist in the
healthcare facility B. She gets hospitalized and is being seen by a group of healthcare
professionals: oncologists, laboratory practitioners, pharmacists, and nurses.
All HCPs involved in the patient care will contribute to the patient‘s record in order to capture
relevant medical information required for the continuity of patient care using different healthcare
information edge systems, such as an Electronic Medical Record system (EMR), a Laboratory
Information System (LIS), and a Radiology Information System (RIS).
All systems need up-to-date CPT codes so that seamless flow of coding results. Currently the
update is achieved via application-specific processes on a system by system basis, which
increases the risk of error when updating value sets in multiple systems.
The laboratory personnel will use a common CPT code to record the examination of a cytology
specimen. The patient will undergo an imaging procedure. This information is captured in the
RIS system, as an internal code. The oncologist sees the patient and makes her own report, but
her application does not have the most recent CPT codes. The administration assistant will have
to code this information in the EMR. Based on all this information, a discharge summary is
created. Nevertheless, there is a gap in the flow of information.
The discharge summary is then published to a repository for healthcare facility B. The PCP can
then retrieve it (via XDS, for example).
Two potentially undesirable outcomes can happen: either the correct billing information will not
reach the provider, or the medical information is not machine processable and cannot be
incorporated in other systems.
If the coding is not uniform across the institution, discrepancies will result, both in medical and
billing terms.
The system used by the document source has access to the above mentioned encoded terms,
having a complete nomenclature, but the application that the PCP uses does not have it, using
instead a more general, and less specialized value set.
The flow of health information is interrupted. Since the PCP‘s application does not have this
information, the user will be able to obtain this information only by reading the narrative part of
the document, but the information will be lost for further processing by the application. There is
no possibility of doing a data extraction needed for data mining or for public health.
Manual reconciliation will have to be done in order to obtain the correct billing information
needed for the reimbursement for the patient, resulting in wasted resources and delays.
Y.3.2.2 Desired state
The hospital retrieves the significant CPT codes from the local Value Set Repository so that all
the applications are using the same nomenclature. This way, the medical and billing information
will flow seamlessly.
Y.3.3 HCPs Nomenclature Tables‘ Update
Y.3.3.1 Current state
GIP-CPS (Carte de Professionals de Santé) – or ―The healthcare professional‘s Card‖ is the
French governing entity responsible for issuing cards for the identification and the authentication
of the healthcare professionals.
The CPS is responsible for handling the directory called ―Shared HealthCare Professionals‘‘
Classification‖ or the RPPS (Le Répertoire Partagé des Professionnels de Santé). This directory
contains tables describing the certain characteristics related to the HCP‘s profession such as their
discipline, their specialty, etc (see tables below).
This HCP nomenclature is not part of the software dealing with reimbursement, but it is installed
by the vendors upon installation. The old nomenclature is called ADELI.
This nomenclature concerns the HCP data and it is installed while the CPS components were
installed (API-CPS), at the original time of the implementation of the system, in some cases ten
years ago.
The ensemble of the patient card and the HCP‘s card is handled by SESAM-Vitale. The exiting
nomenclature serves to give meaning to the data that is read by the card reader.
Examples of data (nomenclature) found in the tables that need to be loaded onto the application
Owner‘s identification (Table G03 Title) and (Table G08 Owner‘s ID)
Monsieur DOC1790 KIT - A 0B1017900
Card identification (Table G01 Card Category and G02 Card type)
Carte de Professional de Santé (CPS) n° 2100570099 de test
Type of qualification
1- General Practitioner (Table G11 type of qualification)
Special disciplines (Table G13)
Homeopathy
Acupuncture
Other qualifications (Table G18)
Coroner
Insurance physician
 As a final example, the currently existing tables (the ADELI nomenclature) can be seen
underneath. They are flat list tables.

Table Y.3.3.1-1. French HCP designation tables
Table ID Table Designation        G00 Language Codes         G01 Card‘s Category          G02 Cart
Type CPS       G03 Civil status     G04 Level of responsibility       G05 Pharmacist‘s
table     G06 Civil status abridged     G07 Health Facility ID Type        G08 ID Carrier
Types      G09 Provinces‘ Codes        G11 Type of
qualification    G12 Specialties       G13 Special certifications     G14 Professional
situation    G15 Professions       G16 Professions (students)       G17 Situation of
exercise     etc…
Y.3.3.2 Desired Situation
The HCPs nomenclature will be distributed from a centralized repository in order to have a
unique nomenclature (RPPS) for replacing the ADELI nomenclature. This process cannot be
accomplished manually. In addition, this nomenclature could be subject to change. The
nomenclature could be changed by the authority concerned (colleges, the government, or
obtaining a new diploma). Those versions are indexed, and are available to any information
system needing information such as ID type, profession, medical specialty, diploma, etc.
Implementing such a centralized source of information implies saving time with the
simplification of the cross-reference update processes, but also increasing the reliability of
information systems that are permanently linked to this source and can download the desired
information anytime.
Y.3.4 Consistent Encoding Terms for anatomical regions in imaging
Y.3.4.1 Current state
In hospital A, an imaging technologist is about to start a CT procedure. S/he chooses its protocol
and estimates what body part s/he should be entering in the ―body part‖ field present on the
machine since nothing was officially configured. The modality will over-ride the RIS
information that the RIS administrator has entered for the CT exams, or it might take the existing
RIS information, depending on the vendor and on the implementation.
The study is sent to the local PACS of healthcare facility A, and a manifest is sent to the
Repository A. Hospital B wishes to retrieve the study by querying the Registry.
Alternatively, the patient will bring the study performed in hospital A on a CD to be imported
into the local system of hospital B via IRWF (Import Reconciliation Workflow). The
nomenclature used for ―body part‖ in the RIS from hospital A is not consistent with the encoding
chosen and in use by the RIS in hospital B. The local PACS and RIS administrator need to
place an order in the RIS and manually reconcile the study so that it will have the same body part
to ensure the same display (hanging protocols for the radiologists).
Y.3.4.2 Desired state
In hospital A, an imaging technologist is about to start a CT procedure. S/he does not have to
worry that the ―body part‖ might be incorrectly configured since the modality and the RIS have
downloaded the latest Value Set for the Anatomical Region. The study is sent to the local
PACS of healthcare facility A, and a manifest is sent to the Repository. Hospital B wishes to
retrieve the study.
Alternatively, the patient will bring the study performed in hospital A on a CD to be imported
into the local system of hospital B via IRWF (Import Reconciliation Workflow). The
nomenclature used for ―body part‖ in the RIS from hospital A is consistent with the encoding
chosen and in use by the RIS in hospital B because hospital B has also downloaded the same
nomenclature from the Value Set Repository. The local PACS and RIS administrator need not
to worry that the radiologist will not see the images displayed according to the department‘s
hanging protocols.
A set of flat list values that can be used for such purposes is DICOM Part 16, CID 4031
Common Anatomic Regions, of which an excerpt can be seen below:

Table Y.3.4.2-1. CID 4031
Excerpt from the Common Anatomic Regions Context ID 4031 Common Anatomic Regions,
Type: Extensible Version 20061023

Coding Scheme
Designator (0008,0102) Code Value
(0008,0100) Code Meaning
(0008,0104)      SRT T-D4000 Abdomen               SRT R-FAB57 Abdomen and
Pelvis    SRT T-15420 Acromioclavicular joint             SRT T-15750 Ankle joint          SRT T-
280A0 Apex of Lung          SRT T-D8200 Arm             SRT T-60610 Bile duct          SRT T-
74000 Bladder        SRT T-04000 Breast            SRT T-26000 Bronchus           SRT T-12770
  Calcaneus      SRT T-11501 Cervical spine
Y.3.5 Modification of a protocol code for a mammogram exam
Radiology departments or healthcare enterprises define local codes that are used in common by
the systems in use, accordingly to the local policies and their workflow.
According to the Mammography Acquisition workflow, codes are used for:
scheduling and driving modality behavior (Requested Procedure, Reason for Requested
Procedure and Scheduled Protocols)
documenting the images and the workflow status: codes for Performed Procedure, Performed
Protocols, Views, etc. enable displays to present images in adequate hanging protocols
enabling radiological staff to track performed work or chose the right billing code.
The profile further states that it important that a department or enterprise defines the code sets
which are used by all of its systems in a common way, and that each relevant code set is
available to each system with the same valid content. Each system needs to be configurable as to
which code sets it uses. IHE Radiology does not (yet) defines a mechanism how to distribute
code sets commonly in organizations.
This way of working contributes to the development of local protocols like ―routine screening‖,
―magnification‖, ―CAD‖, that are understood by technologists or doctors, but could not be
applied to another department or enterprise, nor by the modality in the scope of an automated
error correction.
Moreover, those codes are subject to be modified, removed, declared obsolete, or simply
dropped. This situation is confusing since the RIS list of protocol codes cannot be fully reliable
anymore.
Despite technical means defined in the Scheduled Workflow and Mammography Image Profiles,
variances in the way users and systems behave can lead to department inefficiencies, ambiguous
data, special cases for automated billing, and less than optimal acquisition and reading
environments.
Y.3.5.1 Current state
A patient comes in for a scheduled standard screening mammogram. While the acquisition is
processed, a suspicious lump is detected, and additional views are required, taken by the
technologist. A diagnostic mammogram was performed instead of the simple routine screening
that was scheduled. This information must be then communicated to the RIS, in order to change
the billing codes and implicitly change the hanging protocol for the radiologist. As it is, the
technologist has to manually change the procedure.
The procedure code will have to be corrected in the RIS post-examination so that the correct
information is captured, both for display and for billing purposes.
Y.3.5.2 Desired state
Changing a procedure code should be done directly from the modality, avoiding a subsequent
intervention that can generate errors, misunderstandings, or discrepancies. SVS provides the
modality with a mechanism for accessing a standardized, centralized and dedicated Value Set.
A Value Set, dedicated to mammography procedure codes is made available thought the Value
Set Repository.
The modality, acting as a Value Set Consumer, retrieves the Value Set commonly used by and
defined for the mammography exams.
The correct type of the exam is processed (or at least provides the technologist the ability to
choose the right item from this list).
The list proposed is a flat list, and is pending approval in the DICOM standard.

Table Y.3.5.2-1: Codes for Procedures

Coding Scheme Designator (0008,0102) Code Value (0008,0100)
Code Meaning (0008,0104)    IHERADTF MAWF0001 Screening Mammography,
bilateral    IHERADTF MAWF0002 Screening Mammography,
left    IHERADTF MAWF0003 Screening Mammography,
right     IHERADTF MAWF0004 Diagnostic Mammography,
bilateral    IHERADTF MAWF0005 Diagnostic Mammography,
left    IHERADTF MAWF0006 Diagnostic Mammography,
right     IHERADTF MAWF0007 Mammary Ductogram, Single Duct,
left    IHERADTF MAWF0008 Mammary Ductogram, Single Duct,
right   IHERADTF MAWF0009 Mammary Ductogram, Multiple Ducts,
left   IHERADTF MAWF0010 Mammary Ductogram, Multiple Ducts,
right    IHERADTF MAWF0011 Mammogram for marker placement,
left    IHERADTF MAWF0012 Mammogram for marker placement,
right    IHERADTF MAWF0013 Needle Localization, Image Guided, Mammography,
left    IHERADTF MAWF0014 Needle Localization, Image Guided, Mammography,
right    IHERADTF MAWF0015 Stereotactic Biopsy, Image Guidance,
left    IHERADTF MAWF0016 Stereotactic Biopsy, Image Guidance,
                                                                                            right
                                                                                                 I
                                                                                            HER
                                                                                            ADT
                                                                                            F
                                                                                            MA
                                                                                            WF0
                                                                                            017
                                                                                              Br
                                                                                            east
                                                                                            Spec
                                                                                            imen
                                                                                            Mam
                                                                                            mogr
                                                                                            aphy
                                                                                            ,
                                                                                            left
                                                                                              IH
ERADTF MAWF0018 Breast Specimen Mammography,
right   IHERADTF MAWF0019 Quality Control,
Mammography        IHERADTF MAWF0020 Additional Mammography Views
Note: These are provisional values, whose inclusion in the DICOM Standard is currently
requested (see RAD TF-1: B.2.ZA).




Table Y.3.5.2-2: Codes for Reasons for a Requested Procedure
Coding Scheme Designator (0008,0102) Code Value (0008,0100) Code Meaning
(0008,0104)     Procedure type     IHERADTF MAWF0030 Recall for technical
reasons    IHERADTF MAWF0031 Recall for imaging
findings    IHERADTF MAWF0032 Recall for patient symptoms/ clinical
findings    DCM 111416 Follow-up at short interval from prior study         SRT R-
42453 Screening (Note 1)       SRT R-408C3 Diagnostic (Note 1)           SRT A-
04010 Implant (Note 1)      Note 1: These code values originate from DICOM CID 6061
(DICOM PS 3.16).
Note: These are provisional values, whose inclusion in the DICOM Standard is currently
requested (see RAD TF-1: B.2.ZA).
Y.4 Actors/ Transactions
  Figure Y.4-1 shows the actors directly involved in the SVS Integration Profile and the relevant
transa
ctions
betwe
en
them.
Other
actors
that
may
be
indire
ctly
involv
ed
due to
their
partici
pation
in other related profiles are not necessarily shown. As well, the creation of a Value Set is not
covered by this profile (this subject will be addressed once the basic infrastructure is in place).
Figure Y.4-1 SVS Actor Diagram
Table Y.4-1 lists the transactions for each actor directly involved in the SVS Profile. In order to
claim support of this Integration Profile, an implementation must perform the required
transactions (labeled ―R‖). Transactions labeled ―O‖ are optional. A complete list of options
defined by this Integration Profile is listed in Volume I, Section 1.3.

Table Y.4-1. SVS Integration Profile - Actors and Transactions
Actors Transactions Optionality Section in Vol. 2           ValueSet Repository Retrieve
ValueSet R Z.XX          ValueSet Consumer Retrieve Value Set R Z.XX                 Y.5 SVS
Integration Profile Options
Options that may be selected for this Integration Profile are listed in the table 1.3-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified in
notes.

Table Y.5-1 Sharing Value Sets - Actors and Options

Actor Options Vol & Section         Value Set Repository No options defined - -    Value Set
Consumer No options defined - -          Y.6 SVS Process Flow
This section describes the process and information flow when a Value Set Consumer will
retrieve a Value Set from a Value Set Repository.

Figure Y.6-1. Basic Process Flow in SVS Profile
Y.7 SVS Security Considerations
The asset in the SVS is not patient specific, so there are no risks to privacy. Some Value Sets are
of little value to an attacker as they are public tables of non-critical information (e.g. public
Value Sets, Value Sets used for coding of body part in medical exams...). For other Value Sets,
they might be particularly relevant if malicious modification and/or interception allow potential
gain for the perpetrator (e.g. Value Sets protected by intellectual property, Value Sets used for
financial decision like reimbursement...).

The risks applicable to the SVS profile are discussed in the table ―Risks associated with the
profile SVS‖ which is found on the ftp site. Integrity risks (masquerade or modification of the
value set) and privacy / confidentiality risks (interception) are considered as possibly relevant
depending of the nature of the value sets exchange. The sensibility of the Value Sets used can
only be determined by local risk assessment at the implementation level. As a consequence, the
profile will allow mitigation of those risks when needed:

A Value Sets Repository shall be grouped with a Secure Node or Secure Application. Value Set
Repositories should be able to restrict access to a specific Value Set to authorized and
authenticated nodes, while allowing unauthenticated network queries to other Value Sets.

Given the wide variety of systems that will be retrieving value sets (e.g. embedded medical
device versus PACS) the profile does not mandate this grouping. Depending on local risk
assessment, local policy may mandate the grouping of Value Sets consumers with Secure Nodes
or Secure Applications. IHE does require the ability to configure a Value Set Repository to be
grouped with a Secure Node or Secure Application .
<Appendix A> Actor Summary Definitions
Value Set Repository: actor whose role is to store the brand new or updated Value Sets.

Value Set Consumer: an actor who retrieves a specific new or updated Value Sets based on its
OID.
<Appendix B> Transaction Summary Definitions
Retrieve Value Set: The Value Set Consumer retrieves a new or an updated Value Set from the
Value Set Repository.
Volume 2 - Transactions
Add sections 3.XX
3.XX Retrieve Value Set
This section corresponds to Transaction ITI-XX of the IHE ITI Technical Framework. The Value
Set Consumer and Value Set Repository actors use transaction ITI-XX.

Integration Profiles using this Transaction  Sharing Value Sets (SVS)       3.XX.1 Scope
This transaction is used by the Value Set Consumer to retrieve a Value Set from the Value Set
Repository. The Value Set Consumer has previously obtained the Value Set OID by means
outside of the scope of this transaction.
3.XX.2 Use case roles

  EMBED Microsoft Office Word Picture
Figure 3.XX.2: Use Case Roles
SVS Actors:
Actor: Value Set Consumer
Role: Obtains a Resolved Value Set
Actor: Value Set Repository
Role: Provides a Resolved Value Set

3.XX.3 Referenced Standard
Appendix V

 ITI TF-2:Appendix V Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

3.XX.3.1 Informative References
J. Walker & all. The Value Of Health Care Information Exchange And Interoperability. Health
Affairs – The Policy Journal of the Health Sphere. 19 January 2005. HYPERLINK
"http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.10/DC1"     http://content.healthaffair
s.org/cgi/content/full/hlthaff.w5.10/DC1 (February 10, 2008).
Semantic Interoperability Centre Europe. Semic.eu.          HYPERLINK
"http://www.semic.eu/about.html" \l "chapter3"         http://www.semic.eu/about.html#chapter3 .
(February 10, 2008).
pan-Canadian iEHR Standards. iEHR Terminology Overview. Version 1.3. October 23, 2006.
Canada Health Infoway.
HL7 Common Terminology Services.           HYPERLINK
"http://informatics.mayo.edu/LexGrid/downloads/CTS/specification/ctsspec/cts.htm"
    http://informatics.mayo.edu/LexGrid/downloads/CTS/specification/ctsspec/cts.htm .
Common Terminology Services 2 (CTS 2). Service Functional Model Specification.
   HYPERLINK
"http://biomedgt.org/apelcore/index.php/HL7_Common_Terminology_Services_2_Service_Fun
ctional_Model_%28SFM%29/"
    http://biomedgt.org/apelcore/index.php/HL7_Common_Terminology_Services_2_Service_F
unctional_Model_%28SFM%29/
Reviewer‘s Note: As an informative reference as to how the CTS standard ties in with the SVS
profile, please see the IHE wiki under SVS Discussion and Comments.
3.XX.4 Interaction Diagram

  EMBED Microsoft Word Picture
Figure 3.XX.4: Interaction Diagram

3.XX.4.1 Retrieve Value Set Request
3.XX.4.1.1 Trigger Events
Having obtained the Value Set Unique ID, the Value Set Consumer will start the Retrieve Value
Set Request with the Value Set Repository.
3.XX.4.1.2 Message Semantics
The Retrieve Value Set Request shall carry the following information:
A required Value Set Unique ID that identifies the Value Set within the Repository.
An optional Value Set Version that identifies a specific version of the Value Set.
Section 3.XX.5 describes the Web Services protocol requirements and the format of the message
in full detail.
3.XX.4.1.3 Expected Actions
When receiving a Retrieve Value Set Request, a Value Set Repository shall generate a Retrieve
Value Set Response containing the Resolved Value Set that corresponds to the request
parameters, or an error codes if the Value Set could not be retrieved. If no version is specified,
then the most recent version shall be returned.
3.XX.4.1.4 Security Considerations
This transaction shall be configurable to comply with the security requirements defined in
appendix V.
A Value Sets Repository shall be grouped with an ATNA secure node / secure application.
Repositories should be able to restrict a Value Set to secured network queries, while allowing
non-secured network queries to other Value Sets.
Given the wide variety of systems that will be retrieving value sets (e.g. embedded medical
device versus PACS) the profile does not mandate ATNA grouping. Depending on local risk
assessment, local policy may mandate the grouping of Value Sets consumers with ATNA secure
nodes/ secure applications and the activation of ATNA functionalities (authentication, secured
communications through TLS, audit trails).
3.XX.4.2 Retrieve Value Set Response
3.XX.4.2.1 Trigger Events
This message will be triggered by a Retrieve Value Set Request Message.
3.XX.4.2.2 Message Semantics
The Retrieve Value Set Response Message shall carry the following information for the returned
Value Set:
A required Value Set Unique ID that identifies the value set within the repository. This ID shall
be the same as the Value Set Unique ID in the original Retrieve Value Set Request Message.
A required Value Set Name that can be used for display purposes.
A required Value Set Version, that identifies the specific version of the Value Set returned if
available.
One or more Code System IDs which identify the code system(s) from which the members of the
Value Set are coming from.
List of Value Set Concepts, which constitute the Resolved Value Set.

For each Value Set Concept, the following metadata is returned:
A required Value Set Concept code
A required Value Set Concept name scope of profile
A required Code System identifier
Section 3.XX.5 describes the Web Services requirements and the format of the message in full
detail.
3.XX.4.2.3 Expected Actions
A Value Set Repository shall retrieve the Value Set indicated in the request.
The Value Set Repository shall return the value set or an error code in case the Value Set could
not be retrieved. The following error responses may be returned:
A SOAP fault, whose code value is ―NAV‖, and reason is ―Unknown value set‖
A SOAP fault, whose code value is ―VERUNK‖, and reason is ―Version unknown‖.
3.XX.4.2.4 Security Considerations
Please see section 3.XX.4.1.4 Security Considerations
3.XX.5 Protocol Requirements
The protocol for the Retrieve Value Set is based on SOAP 1.2.
WSDL Namespace Definitions
soap12 http://schemas.xmlsoap.org/wsdl/soap12/         wsaw http://www.w3.org/2006/05/addres
sing/wsdl/     xsd http://www.w3.org/2001/XMLSchema            ihe urn:ihe:iti:svs:2008     These
are the requirements for the Retrieve Value Set transaction presented in the order in which they
would appear in the WSDL definition:
The following types shall be imported (xsd:import) in the /definitions/types section:
namespace="urn:ihe:iti:svs:2008", schema="SVS_ValueSetRepository.xsd"
The /definitions/message/part/@element attribute of the Retrieve Value Set Request message
shall be defined as ―ihe:RetrieveValueSetRequest‖
The /definitions/message/part/@element attribute of the Retrieve Value Set Response message
shall be defined as ―ihe:RetrieveValueSetResponse‖
The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Value Set
Request message shall be defined as ―urn:ihe:iti:2008:RetrieveValueSet‖
The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Value Set
Response message shall be defined as ―urn:ihe:iti:2008:RetrieveValueSetResponse‖
The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be defined as
―urn:ihe:iti:2008:RetrieveValueSet‖
These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Full
sample request and response messages are in section REF _Ref167821063 \h \*
MERGEFORMAT 3.XX.5.1 Sample SOAP Message .
An informative WSDL file for the Value Set Repository actor can be found on the IHE ftp site
(see Appendix W).
Within the request message payload the <ihe:RetrieveValueSetRequest/> element is defined as:
A required /ihe:RetrieveValueSetRequest/ihe:ValueSet element that identifies the value set
within the repository via its id attribute.
An optional /ihe:RetrieveValueSetRequest/ihe:ValueSet@version attribute.
Within the response message payload, the <ihe:RetrieveValueSetResponse/> element is defined
as:
A required /ihe:RetrieveValueSetResponse/ihe:ValueSet element, containing
a required /ihe:RetrieveValueSetResponse/ihe:ValueSet@id attribute
a required /ihe:RetrieveValueSetResponse/ihe:ValueSet@displayName attribute
a required /ihe:RetrieveValueSetResponse/ihe:ValueSet@version attribute
zero or more /ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:SourceCodeSystem elements,
where the lack of this element indicates that the value set itself is a code system
a required /ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:ConceptList element, containing
one or more /ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:ConceptList/ihe:Concept
elements, representing the concepts within the value set.
The <ihe:SourceCodeSystem/> element contains an id attribute, representing the source code
system OID.
The <ihe:Concept/> element is defined as being of the HL7 V3 CD data type.
A full XML Schema Document for the SVS types is available on the IHE ftp site (see Appendix
W).
3.XX.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,
<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
W3C WS-Addressing standard.
All of the samples presented in this section are also available online on the IHE FTP site (see
Appendix W).
3.XX.5.1.1 Sample Retrieve Value Set SOAP Request
Note to the editor: please keep the following format for the sample text – courier new, 8pt, no
spacing before and after the paragraph, tab stops every 1/8 of an inch for the first inch.

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
  xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
     <a:Action s:mustUnderstand="1">urn:ihe:iti:2008:RetrieveValueSet</a:Action>
     <a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID>
     <a:ReplyTo>
       <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
     </a:ReplyTo>
     <a:To s:mustUnderstand="1">http://valuesetrepository/</a:To>
  </s:Header>
  <s:Body>
     <RetrieveValueSetRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="urn:ihe:iti:svs:2008">
       <!-- If no version is specified, requesting the latest version -->
       <ValueSet id="1.3.6.1.4.1.21367.2008.999999.1"/>
     </RetrieveValueSetRequest>
  </s:Body>
</s:Envelope>
3.XX.5.1.2 Sample Retrieve Value Set SOAP Response
Note to the editor: please keep the following format for the sample text – courier new, 8pt, no
spacing before and after the paragraph, tab stops every 1/8 of an inch for the first inch.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
   xmlns:a="http://www.w3.org/2005/08/addressing">
   <s:Header>
     <a:Action s:mustUnderstand="1">urn:ihe:iti:2008:RetrieveValueSetResponse</a:Action>
     <a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo>
   </s:Header>
   <s:Body>
     <RetrieveValueSetResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="urn:ihe:iti:svs:2008">
        <ValueSet id="1.3.6.1.4.1.21367.2008.999999.1"
     displayName="Codes for Reasons for a Requested Procedure" version="5.7.2"/>
        <SourceCodeSystem id="2.16.840.1.113883.6.5"/>
        <SourceCodeSystem id="1.2.840.10008.2.16.4"/>
        <ConceptList>
          <Concept code="R-42453" displayName="Screening"
codeSystem="2.16.840.1.113883.6.5"/>
          <Concept code="R-408C3" displayName="Diagnostic"
codeSystem="2.16.840.1.113883.6.5"/>
          <Concept code="A-04010" displayName="Implant"
codeSystem="2.16.840.1.113883.6.5"/>
          <Concept code="MAWF0030" displayName="Recall for technical reasons"
codeSystem="1.2.840.10008.2.16.4"/>
          <Concept code="MAWF0031" displayName="Recall for imaging findings"
codeSystem="1.2.840.10008.2.16.4"/>
          <Concept code="MAWF0032" displayName="Recall for patient symptoms/ clinical
findings" codeSystem="1.2.840.10008.2.16.4"/>
          <Concept code="111416" displayName="Follow-up at short interval from prior study"
codeSystem="1.2.840.10008.2.16.4"/>
        </ConceptList>
     </RetrieveValueSetResponse>
   </s:Body>
</s:Envelope>
3.XX.6 Security Requirements
A Value Sets Repository shall be grouped with an ATNA secure node / secure application.
Repositories should be able to restrict a Value Set to secured network queries, while allowing
non-secured network queries to other Value Sets.
Given the wide variety of systems that will be retrieving value sets (e.g. embedded medical
device versus PACS) the profile does not mandate ATNA grouping. Depending on local risk
assessment, local policy may mandate the grouping of Value Sets consumers with ATNA secure
nodes/ secure applications and the activation of ATNA functionalities (authentication, secured
communications through TLS, audit trails).

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:11/14/2011
language:English
pages:28