IHE_Supp_ITI_Sharing-Value ... - Dicom

IHE International Integrating the Healthcare Enterprise [pic] IHE ITI Technical Framework Supplement 2008-2009 Sharing Value Sets
(SVS)
Draft Draft following meeting face to face March 10 - 13, 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 American College of Cardiology (ACC),
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 V4.0 is submitted for
Public Comment between May XX, 2008 and June XX, 2008, per the schedule
announced in XXXX 2008. Comments shall be submitted before May XX, 2008 to: http://forums.rsna.org under the "IHE" forum Select the "ITI Supplements for Public Review" sub-forum. The IHE ITI Technical Committee will address these comments and publish the
Trial Implementation version in August 2008.
Date: Mar. 12, 2008 These" boxed" instructions for the author to indicate to the Volume Editor
how to integrate the relevant section(s) into the overall Technical
Framework Replace Section X.X by the following: Introduction
Sharing Value Sets (SVS) provides a means through which healthcare
facilities such as primary care physician offices, healthcare
facilities, healthcare networks, and national healthcare record systems
can receive a common, shared terminology managed in a centralized
fashion. SVS supports a mechanism of querying a Value Set Repository to
retrieve a given Value Set by a Value Set Consumer. This mechanism can be applied on a small scale, such as within a
healthcare facility, or on a larger scale, such as a RHIO (Regional
Health Information Organization) or a national healthcare record system.
In all these cases, a Terminology Source would be involved, be it in-
house or an official source, depending on the perimeter of the actions
required. This Supplement defines an infrastructure profile, which when will
integrate domain-specific content standards; a much greater level of
interoperability will result.
1 Open Issues and Questions
1. The Value Set retrieval is modeled after the Document Set retrieval
mechanism in XDS.b. As the SVS profile develops, a possibility that
was mentioned was it to be kept in alignment with the XDS.b model. The
delineation between the two must be established. The standard ebXML
will not be used. A way of packaging the CTS API (language binding)
must be found. 2. Should a language be a parameter for the Value Set retrieve
transaction? It is possible, but the Repository will have to work
harder. This topic is of international interest. In the context of
the use in Québec for example, separate designations will have to be
used. This issue will have to be revisited. 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 a separate
look-up process, and not part of the XML wrapping. The process of
building this into an application will have to be looked at. The
process is a little less granular (less granular then what?). A
second parameter might be added. The Repository will be built on the
second layer and it will respond by bringing back the requested
language. 3. The issue around what will give the right language is still an open
one. If there was a Registry, then the issue will become easier to
deal with. Another question was asked if there could be two
conflicting Value Sets in different languages. The answer is that
each Value Set has its own separate OID, therefore this is not an
issue. The committee has decided not to address at the moment the
language issue. 4. A question should be addressed about the asynchronous mode. Is the
profile stating explicitly that web services are to be used? If the
initial reader might see web services, they might think that the
asynchronous mode is not being 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. 5. Should we add the ISO definitions in the Glossary or place it in the
Annex? Are they relevant or contradictory? A suggestion was made to
use only the definitions used in HL7 terms and see how it will
correlate with ISO. The editor will add the ISO definitions to the
HL7 definition and a common glossary will be constructed with the
working group CTS2. 6. An issue that was not discussed at the face to face is the possibility
to use portable media to exchange Value Sets. 7. Thomas' comment from the wiki integrated as an open issue that needs
to be adressed Within Survey instruments which are stored in LOINC, LOINC itself stores
the value set for each question which requires an enumerated of answers
(e.g. the MDS, SF-36, etc.). These are stored as "LA" (LOINC answer part)
codes linked to the LOINC code (which uniquely identifes both the question
and the valueset). So, if an OID is required for this type of value set,
there seems to be duplication of effort and risk of keeping the OIDS and
LOINC codes in sync. Has this issue been addressed? If not, I'd be happy
to speak to the group for a few minutes about this. My biggest concern is
that I have over 1000 instruments in the mental health domain which I want
to make interoperable. LOINC will store them; and we have a process for
mapping content to SNOMED and messaging via HL7 2.5. I'd like to message
any arbitrary standardized instrument via CCD, but if I have to both get
LOINC codes for each valueset and get OIDS, this could slow down our
efforts.