21 Sharing Value Sets (SVS)

The Sharing Value Sets (SVS) Profile provides a means through which healthcare systems producing 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, uniform nomenclature managed centrally. Shared nomenclatures are essential to achieving semantic interoperability.

A single Value Set Repository can be accessed by many Value Set Consumers, establishing a domain of consistent and uniform set of nomenclatures. It supports automated loading of Value Sets by Value Set Consumers, reducing the burden of manual configuration. This profile describes two transactions for retrieving Value Sets from a Value Set Repository by a Value Set Consumer.

• A single value set can be retrieved based on an OID value. This is aimed at meeting the needs of systems that are pre-configured to use specific value sets. These systems are often medical devices with strictly controlled functions that should not be modified without careful review. This transaction does not include metadata content, and provides just the value set concept list as uniquely identified in the request.
• Multiple value sets can be retrieved based on metadata about the value sets. This is aimed at meeting the needs of systems and users that will be dynamically selecting value sets, deciding which value sets should be used, and creating new value sets based on the contents of existing value sets. This transaction supports much richer selection criteria and provides metadata descriptions as well as the contents (expanded lists of coded values) of all the value sets that meet those criteria.

Both transactions provide access to centrally managed value sets that have been assigned metadata, including group identification. The ability to identify groups of value sets is essential to achieving semantic interoperability and development of modular structures of electronic health records (EHR). Group identification can be used to identify, for example, all the value sets needed for a given purpose like filling in a particular kind of report.

21.1 SVS Actors/Transactions

Figure 21.1-1 shows the actors directly involved in the SVS Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in other related profiles are not necessarily shown. As well, the method for creating a Value Set is not covered by this profile (this subject will be addressed once the basic infrastructure is in place).

Table 21.1-1 SVS - Actors and Transactions lists the transactions for each actor directly involved in the SVS Profile. In order to claim support of this profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this profile is listed in Table 21.2-1.

Table 21.1-1: SVS - Actors and Transactions

Actors	Transactions	Optionality	Section
Value Set Repository	Retrieve Value Set [ITI-48]	R	ITI TF-2: 3.48
	Retrieve Multiple Value Sets [ITI-60]	R	ITI TF-2: 3.60
Value Set Consumer	Retrieve Value Set [ITI-48]	R	ITI TF-2: 3.48
	Retrieve Multiple Value Sets [ITI-60]	O	ITI TF-2: 3.60

21.1.1 SVS Required Actor Groupings

An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).

Table 21.1.1-1: SVS - Required Actor Groupings

SVS Actor	Actor(s) to be grouped with	Reference
Value Set Repository	CT / Time Client	ITI TF-1: 7.1
	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1
Value Set Consumer	None	--

21.1.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 expressions drawn from multiple code systems (a code system is a system consisting of designations and meanings, for example LOINC, SNOMED-CT, ICD-10, or ISO 639 Language Codes).

This profile will address a flat list of concept codes, one of the simplest examples of a Value Set being shown in Table 21.1.2-1.

Table 21.1.2-1: The Provinces of Canada

Provinces of Canada ISO Code	Print Name
NL	Newfoundland
AB	Alberta
BC	British Columbia
SK	Saskatchewan
MB	Manitoba
ON	Ontario
QC	Quebec
NB	New Brunswick
NS	Nova Scotia
PE	Prince Edward Island

21.1.3 Value Set Unique ID and Value Set Version

A Value Set must be uniquely identified to allow various applications and users to recognize it. When a Value Set is retrieved, the application or the user is retrieving a particular instance of it, or an Expanded Value Set (an Expanded Value Set is a set of concept representations that were in effect at a specific time for a particular version of a Value Set definition. The Value Set (definition) and the Expanded Value Set concepts are similar to the programming concepts of Class and Instance of Class.)

This profile uses the Value Set Unique ID (using an ISO OID), and the Value Set Version attributes to allow flexible handling of the identification of a Value Set.

The actual set of codes derived from this definition of a Value set is an Expanded Value Set . SVS supports the sharing of Expanded Value Set with two different approaches to their identification:

1. By unique identification of the Expanded Value Set itself, and no reference to the definition that produced it. Such an Expanded Value Set carries its own unique identifier (i.e., an OID and Version).
2. By reference to the Value Set definition (OID and Version) from which the Expanded Value Set was derived. In this case specific Expanded Value sets (derived from the same Value Set definition) are only distinguished by their expansion date and time.

21.1.4 The relationship between ITI SVS and CTS

The Value Set Repository can be supported by a system that implements a Terminology Server using the current HL7 CTS or the upcoming HL7 CTS2 specifications. It is important to note the complementary role of the HL7 specification for CTS and CTS2, and that of the SVS Integration Profile. CTS defines an API (Application Programming Interface) supported by a terminology management service, and CTS2 defines the functionality supported by a terminology management service leaving the specification of the API to the Object Management Group. SVS defines the transmission protocols for a network access to a terminology server focused specifically on the distribution of Value Sets.

However, there is functional consistency between SVS and CTS/CTS2. More specifically, all the properties of the Value Sets and concepts described in the Shared Value Sets Retrieve transaction are a subset of the properties defined in CTS and the CTS2 functional specification for the same entities. Note that SVS supports the distribution of Value Sets containing concepts from multiple code systems (e.g., DICOM and SNOMED issued) which is consistent with the CTS capabilities, but which was not supported in the CTS specifications (but is supported in the CTS2 specification).

Informative references:

1. LexGrid Common Terminology Services.

2. Common Terminology Services 2 (CTS 2). Service Functional Model Specification. (See HL7 site for latest information.)

21.1.4.1 Value Set Distribution Flow

There are three types of value sets supported by the SVS Transactions:

1. Intensional Value Sets are defined in terms of algorithmic and other methods. These value sets can be supported by the Value Set Repository, but this profile does not provide a means to convey the intensional form. Instead, these value sets are described using the metadata, and the appropriate resulting expanded value set contents are returned along with the Intensional Value Set definition and expansion metadata. This profile specifies how these can be retrieved using the Retrieve Multiple Value Sets [ITI-60] transaction.

2. Extensional Value Sets are defined in terms of a list of concepts. As with intensional value sets, the definition and expansion metadata for these can be retrieved along with the appropriate expanded value set contents. This profile specifies how these can be retrieved using the Retrieve Multiple Value Sets [ITI-60] transaction.
3. Expanded Value Sets result from the expansion of any Value Set definition (e.g., Intensional or Extensional), but their definition metadata is not important to the Value Set Consumer, only an identified instantiation defined in terms of a list of specific codes from specific vocabularies is shared. This profile describes how these can be retrieved using either the Retrieve Multiple Value Sets [ITI-60] transaction or the Retrieve Value Set [ITI-48] transaction.

The developers of value sets may choose to work with one or more of these types, but the final consumers of value sets need to work with expanded value sets. There are efforts underway to develop standard methods for exchanging explicit definition of intensional and extensional value sets, but these are outside the scope of the SVS Profile. SVS provides only a way to distribute value sets that have been expanded.

The SVS Profile also restricts the complexity of the expanded value sets. At present, it only supports unstructured value sets that are a list of codes from coded terminologies. Other internal structures such as hierarchy are not defined. This meets the needs of most, but not all, value sets.

The process and rules associated with a value set expansion is not specified nor constrained by this profile. It is the responsibility of the value set developer or of the system supporting the SVS Repository to perform the appropriate expansions. If the value set developer defines their standard distribution format as the expanded form of the value set, they have the appropriate procedures for this expansion. Value set developers that do not have a procedure defined for distributing the expanded form will need to establish one in order to use the SVS Profile.

A value set developer that defines and publishes expanded value sets should also establish the proper identification that identifies either this expanded value set or the definition that resulted in this expanded value set. They also define metadata that describes the value set. (Value set group descriptions will be discussed later.) The metadata is listed below, and includes descriptive information, links to further explanatory material, effective dates, etc. The SVS Profile provides two transactions for retrieving an expanded value set:

1. Retrieve Value Set [ITI-48] – This is appropriate for rapid retrieval of expanded value sets. It retrieves the expanded value set based on having the OID for the value set pre-configured into the system requesting the value set. This transaction does not retrieve the expanded value set metadata nor the value set definition metadata. It only retrieves the list of codes for that expanded value set.
2. Retrieve Multiple Value Sets [ITI-60] – This is appropriate for retrieval of value sets based on metadata contents. It can still retrieve value set expansion based on the value set OID, but can also retrieve value set expansions based on contents of descriptions, OIDs and versions, group labels, dates, etc. This form of retrieval provides both the expanded value set contents for the retrieved value sets and the metadata for the value set.

Value set developers that publish intensional and extensional value sets also defined OIDs for their value sets definitions. Note that a developer may publish multiple forms of related value sets, but will assign each form the proper OID. When publishing with SVS, the value set developer should provide an expanded form that should be provided along with the metadata.

The SVS Profile provides one transaction for retrieving intensional and extensional value sets:

1. Retrieve Multiple Value Sets [ITI-48] – This is appropriate for retrieval of value sets based on metadata contents, including value set OID, but can also be based on contents of descriptions, group labels, dates, etc. This form of retrieval provides both the expanded value set contents for the retrieved value sets and the metadata for the value set. Note that there are other standards efforts defining forms for intensional and extensional value sets. These other forms are intended for use by value set developers. SVS provides the expanded form primarily for value set consumers.

A value set user that receives an intensional or extensional value set must be aware that the expansion is only for representational uses. The other metadata, such as effective dates and the descriptive material, must be consulted to determine the proper use of the expanded form. In practice, value sets change slowly and there is usually time for human review and decision making about the use of the expanded form.

The SVS Profile does not specify how or when this expansion should take place. That is the responsibility of the value set developers and server maintainers. In many cases, the value set developer will provide an expanded form together with effective dates so that the organizations involved can manage change easily.

21.1.4.2 Value Set Groups

Value sets are also described by various grouping and tagging mechanisms. These groupings may be defined in parallel by many different organizations. It is expected that each organization is creating groups for their own purpose. One organization may assign groups like “value sets associated with H1N1”, while another group may assign groups like “value sets associated with clinical trial xyz reports”, and a third may assign groups like “formulary for treatment of H1N1 influenza”. Each of these organizations may assign key words so that retrieval requests can find the relevant groups, and they may assign OIDs for these groups.

To simplify maintenance, SVS defines a list of group descriptions to be associated with each value set, rather than combining all the keywords and groups from different organizations into a single list. The retrieval transaction searches all of these descriptions when doing a retrieval based on group keyword or group OID.

An organization that is creating new groups can define a list of keywords and an OID for that group purpose. This group description can then be attached to each value set that should be a member of that group. If a value set needs to be removed from the group, then the attached description can be removed. This avoids accidental removal of keywords when multiple organizations have used the same keyword

21.1.4.3 Value Set Descriptive Metadata

A value set is described by metadata that includes the fields in Table 21.1.4.3-1. For details on the metadata encoding, see ITI TF-2: 3.60 . Fields are mandatory or optional as shown in the table. Some of the metadata can be used as retrieval criteria for both the [ITI-48] and [ITI-60] transactions, some only for [ITI-60], and some are only returned and cannot be used as retrieval criteria.

Table 21.1.4.3-1: Value Set Metadata Summary

Metadata Element	Description	Optionality	Selection Criteria for Transactions
Id	This is the unique identifier of the value set	Mandatory	ITI-48, ITI-60
DisplayName	This is the name of the value set	Mandatory	ITI-60
Source	This is the source of the value set, identifying the originator or publisher of the information	Mandatory	ITI-60
Purpose	Brief description about the general purpose of the value set	Optional	ITI-60
Definition	A text definition describing how concepts in the value set were selected	Optional	ITI-60
Source URI	Most sources also have a URL or document URI that provides further details regarding the value set.	Optional	-
Version	A string identifying the specific version of the value set.	Mandatory	ITI-48
Status	Active, Inactive, local extensions	Mandatory	-
Type	This describes the type of the value set: Intensional, Extensional, or Expanded Note:   This is the type of the value set in the repository. Value set retrieval will return a value set expansion.	Mandatory	-
Binding	Static or Dynamic	Optional	-
Effective Date	The date when the value set is expected to be effective	Optional	ITI-60
Expiration Date	The date when the value set is no longer expected to be used	Optional	ITI-60
Creation Date	The date of creation of the value set	Optional	ITI-60
Revision Date	The date of revision of the value set	Optional	ITI-60
Groups	The identifiers and keywords of the groups that include this value set. A group may also have an OID assigned.	Optional	ITI-60

Note 1:   Status codes are determined by the Value Set developers. The suggested values shall be used if applicable.

Note 2:   The meaning of binding is not constrained by this profile.

Some of these metadata fields can be specified as part of the selection criteria for retrieve multiple value sets. All of the available metadata is returned as the results from a retrieve multiple value sets. Metadata is not returned for the [ITI-48] transaction.

This profile does not specify how the value set repository is maintained, how new value sets are added, or how existing values sets are updated.

21.2 SVS Actor Options

Options that may be selected for this profile are listed in Table 21.2-1 SVS - Actors and Options, along with the actors to which they apply. Dependencies between options when applicable are specified in notes. Note that the Value Set Consumer shall implement at least one of the two bindings listed as options in the table. The Value Set Repository shall implement both bindings as specified in ITI TF-2: 3.48.5.

Table 21.2-1: SVS - Actors and Options

Actor	Options	Volume and Section
Value Set Repository (See Note)	No options defined	--
Value Set Consumer (See Note)	HTTP binding	ITI TF-2: 3.48.5 , ITI TF-2: 3.60.5.2
	SOAP binding	ITI TF-2: 3.48.5 ITI TF-2: 3.60.5.1
	Retrieve Multiple Value Sets	ITI TF-2: 3.60

Note: A Value Set Consumer must support either the HTTP binding, the SOAP binding or both bindings. The Value Set Repository must support both bindings.

21.2.1 Retrieve Multiple Value Sets Option

Value Set Consumers that support the Retrieve Multiple Value Sets Option shall support the Retrieve Multiple Value Sets [ITI-60] transaction.

21.3 SVS Process Flow

This section describes the process and information flow when a Value Set Consumer retrieves a Value Set from a Value Set Repository. There is no required order between the two transactions. The Value Set Consumer chooses whichever transactions and order are appropriate. The Value Set Consumer can use Retrieve Value Set [ITI-48] to retrieve a single value set based upon a known value set OID. The Retrieve Multiple Value Sets [ITI-60] transaction can be used to retrieve all of the value sets that match a selection specification. The selection criteria for [ITI-60] need not include a known value set OID.

21.3.1 Overview of the entire process flow

This profile describes functionality in the context of the larger system of anticipated actors involved in the creation and management of Value Sets.

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 21.3.1-1, Overview of process flows below, included for clarity’s sake:

Figure 21.3.1-1 shows the Retrieve Value Set transaction in the context of the larger system of anticipated actors involved with the creation and management of Value Sets. This profile only addresses the actors and transactions outlined by the thick solid line.

The SVS Profile addresses partly the semantic interoperability issue and assumes that a structure is already in place to provide the necessary context for the use of the Value Set.

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.

21.3.2 Use Cases

The following use cases indicate how this profile might be used by various disciplines.

Note: All the tables present in the use cases are examples only. IHE will not be responsible for updating these tables.

21.3.2.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.

More detailed information about a possible definition of an Affinity Domain can be found in the Template for XDS Affinity Domain Deployment Planning White Paper.

21.3.2.1.1 Current state

The nomenclature used in the Affinity Domain is being entered into systems manually, a time-consuming task, potentially leading to errors.

21.3.2.1.2 Desired state

Each vendor’s application would retrieve the necessary Value Sets used in a XDS Affinity Domain from a Value Set Repository, eliminating manual entry and improving accuracy.

21.3.2.2 Updating terminology codes for a medical and billing across systems

Standardized coding systems are essential for health insurance programs to ensure that these claims are processed in an orderly and consistent manner.

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.

21.3.2.2.1 Current state

A patient is being referred by her PCP from a small healthcare facility to a large healthcare facility. She gets hospitalized and is being seen by a group of healthcare professionals: oncologists, laboratory practitioners, pharmacists, and nurses.

The patient’s record will contain medical information from 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 encoded information 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 Discharge Summary produced by the hospital lacks coded information about the care received due to the lack of a consistent and uniform nomenclature. The document is then published to a regional repository or saved on a portable media. The PCP can then retrieve it (via XDS or XDM, for example).

Due to the full lack of encoding, 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, with data mining being compromised.

21.3.2.2.2 Desired state

The hospital retrieves the significant CPT codes from the Value Set Repository so that all the applications are using the same nomenclature. This way, the medical and billing information will flow seamlessly, improving the quality of patient care.

21.3.2.3 Consistent Encoding Terms for anatomical regions in imaging

21.3.2.3.1 Current state

In hospital A , an imaging technologist is about to start a CT procedure. S/he chooses its protocol and estimates the body part s/he should be entering manually in the “ body part ” field present on the machine. The modality will over-ride the RIS information that the RIS administrator has configured 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 healthcare facility A local PACS, and a manifest is sent to the XDS Repository A . Hospital B wishes to retrieve the study by querying the XDS 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 (IHE Radiology Import Reconciliation Workflow Profile).

The nomenclature used for “ body part ” in the RIS from hospital A is not consistent with the encoding chosen 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 in order to ensure the same hanging protocols for the radiologists.

21.3.2.3.2 Desired state

In hospital A , an imaging technologist is about to start a CT procedure. S/he chooses the correct “ body part ” from the latest Value Set Anatomical Regions downloaded from the Value Set Repository. The study is sent to the local PACS of healthcare facility A , and a manifest is sent to the XDS Repository A . 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 Profile). The nomenclature used for “ body part ” in the RIS from hospital A is consistent with the encoding chosen by the RIS in hospital B because hospital B has also downloaded the same Expanded Value Set from the Value Set Repository. The radiologist will 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 in Table 21.3.2.3.2-1: CID 4031 Common Anatomic Regions:

Table 21.3.2.3.2-1: CID 4031 Common Anatomic Regions

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

Note: Excerpt from the Context ID 4031 Common Anatomic Regions, Type: DICOM Part 16, OID 1.2.840.10008.6.1.308. The codes in this table are examples; IHE ITI is not responsible for updating these codes over time.

21.3.2.4 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 Profile (MAWF) from the IHE Radiology Technical Framework, 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 MAWF Profile further states that a department or enterprise should define the code sets which are used by all of its systems in a common way, so 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. The lack of a common mechanism for distribution of code sets 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 IHE Radiology Scheduled Workflow and Mammography Acquisition Workflow 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.

21.3.2.4.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 is 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.

21.3.2.4.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 Profile provides the modality with a mechanism for accessing a uniformed, centralized and dedicated Expanded Value Set.

An Expanded 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 Expanded 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.

Table 21.3.2.4.2-1: Codes for Mammography 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
IHERADTF	MAWF0017	Breast Specimen Mammography, left
IHERADTF	MAWF0018	Breast Specimen Mammography, right
IHERADTF	MAWF0019	Quality Control, Mammography
IHERADTF	MAWF0020	Additional Mammography Views

Note: These are provisional values, used as an example (see RAD TF-2: Table 4.5-5). IHE ITI is not responsible for updating this table over time.

Table 21.3.2.4.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 (See Note)
SRT	R-408C3	Diagnostic (See Note)
SRT	A-04010	Implant (See Note)

Note: These code values originate from DICOM PS3.16 CID 6061 and RAD TF-2: 4.5-6). The codes in this table are examples; IHE ITI is not responsible for updating these codes over time.

21.3.2.5 Distributing Value Sets from SDOs and other master sources

There is a bidirectional relationship between the users of terminologies, codes, and value sets at one end, and the standards development organizations (SDOs) and other developers of terminologies, codes, and value sets. The following diagram shows the process by which terminologies and value sets flow up to the value set consumers. The users’ comments and new requirements flow back down to the sources of information.

At the top of this diagram, the value set consumers retrieve values sets from a master value set repository that they need for particular purposes. This could be done with the [ITI-48] transaction when the consumer is configured with specific OID values for specific purposes. Often, there is a need to retrieve a group of value sets that share a common purpose, such as all of the value sets needed to populate a particular kind of report. These retrievals are performed using the [ITI-60] retrieve multiple value sets transaction.

This master value set repository is subject to review and governance. The individual consumers have delegated responsibility for administering and maintaining the master value set repository to a coordinating organization. These organizations may be local, state, regional, or national organizations. They are typically not the developers of standard terminologies. The master repository organization serves an administrative and coordinating purpose to ensure that the releases of standard terminologies from SDOs do not interfere with daily operations of the value set consumers. They may also coordinate requests from value set consumers for new terminologies and value sets. There is a governance committee to coordinate these activities in both directions. These activities are important to the maintenance of the master value set repository. They are not described further as part of this profile.

The terminology developers typically release new terminologies and value sets on a regular schedule or at times matching their process. These notifications may be via bulletins, electronic notification, and other processes. They are not covered as part of this profile. The governance committee may choose to use [ITI-60] as their method of retrieving copies of the SDO value sets, if the SDO has established a value set repository as part of their distribution process.

21.3.2.6 Obtaining value sets based upon metadata

There are often situations where notifications such as emails, bulletins, etc. contain descriptive information rather than a specific OID. Also, there are situations where potentially useful value sets must be found based upon only a description. An example of this kind of use is:

1. A user needs all the value sets for stroke quality care measures from the US Joint Commission. These measures are identified by having a group name containing “stroke”. They plan to use this as the starting point for establishing triggers for decision support and data analytics application operating on data generated for the current year.

2. The user interacts with a Value Set Consumer to request value sets that have a group that includes “stroke”, a source that includes “Joint Commission” or “JCAHO”, and that are effective for the current year.
3.  The Value Set Repository finds all the matching value sets and sends a response containing all the value sets and their descriptive metadata. Because there is also a European Joint Commission, this response includes some extras.
4. Client uses the complete metadata to eliminate the extras that are not relevant to the purpose.

21.4 SVS Security Considerations

The contents handled by the SVS Profile are not patient specific, so there are no risks to privacy. Some Expanded Value Sets are of little value to an attacker as they are public tables of non-critical information (e.g., Expanded Value Sets used for coding of body parts in medical exams). Other Expanded Value Sets might need protection against malicious modification or interception.

The risks applicable to the SVS Profile are in the IHE Google Drive at: Security Risks Associated with the SVS Profile.doc The nature of the Expanded Value Set exchange determines the type or risk that can incur. For example, there can be integrity risks such as masquerade (A malicious server passing for the value set repository gives forged value sets.), or the modification of Expanded Value Sets. Another possible type of risk would be at the privacy and confidentiality level such as the interception of an Expanded Value Set containing confidential data. The profile will allow mitigation of those risks when needed in the following manner:

• A Value Sets Repository shall be grouped with an ATNA Secure Node or Secure Application. Since the Value Set Consumer is not required to be grouped with the Secure Node or Secure Application, the Value Set Repository shall support both secure and non-secure connections.
• Value Set Repositories shall be able to restrict access to a specific Expanded Value Set to authorized and authenticated nodes, while allowing unauthenticated network queries to other Expanded Value Sets.
• Given the wide variety of systems that will be retrieving Expanded Value Sets (e.g., embedded medical device versus PACS) the profile does not mandate that the Value Set Consumer be grouped with an ATNA Secure Node or a Secure Application. Depending on local risk assessment, local policy may mandate such grouping.