Sharing of Value Set - Discussion

Introduction

Sharing value sets detailed proposal

Nov 7-8 Face to Face

Sharing Value Sets discussion

Current work

Current work

Discussion and Comments

SVS Future Considerations

The SVS Profile it is in its early development stages and here are some of the future considerations.

The Relationship between CTS and Web Services

The Value Set Repository actor can be created as a front end (or proxy) to a Common Terminology Server which implements the current CTS or future CTS2 specification. All the properties of the Value Set and Concepts described in this transaction are a subset of the properties defined in CTS (and the current draft of CTS2) for the same entities.

The Retrieve Value Set transaction can then be implemented as a series of API calls within the CTS server.

In addition, note that CTS defines Value Sets as containing concepts from a single Code System, while CTS2 allows concepts from multiple Code Systems.

As seen from the use cases, this profile needs to support Value Sets containing concepts from multiple code systems such as DICOM and SNOMED

Discussions following the talk from Apr. 18, 2008. For those French participants interested in contributing, please do attend these calls so that we do not have to duplicate the work. A simple email discussion is sufficient, followed by a face to face if need really arises. The time of calls has especially changed in order to accomodate all international participants.

[April 18, 2008]

Other Use Cases Not Included in the Supplement

These use cases represent general overview of situations where sharing values sets is part of the solution, as well as use cases for future work on the profile.

1.4.1 Update of multiple code sets across various systems, and affinity domains (Big Picture)

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 United Stated the HCPCS (Healthcare Common Procedure Coding System) Level II Code Set is one of the standard code sets used for this purpose (Code System HL7 OID 2.16.840.1.113883.6.14, symbolic name HCP). The HCPCS is divided into two principal subsystems, referred to as level I and level II.

Level I of the HCPCS is 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 furnished by physicians and other health care professionals. These health care professionals use the CPT to identify services and procedures for which they bill public or private health insurance programs. Level I of the HCPCS, the CPT codes, does not include codes needed to separately report medical items or services that are regularly billed by suppliers other than physicians. Category I CPT codes describe a procedure or service identified with a five-digit CPT code and descriptor nomenclature. The HL7 OID for CPT is 2.16.840.1.113883.6.12, with the symbolic name C4.

Level II of the HCPCS is a standardized coding system that is used primarily to identify products, supplies, and services not included in the CPT codes, such as ambulance services and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) when used outside a physician's office. Because Medicare and other insurers cover a variety of services, supplies, and equipment that are not identified by CPT codes, the level II HCPCS codes were established for submitting claims for these items. The HL7 OID for Level II is 2.16.840.1.113883.6.13, with the symbolic name CD2. Level II codes are also referred to as alpha-numeric codes because they consist of a single alphabetical letter followed by 4 numeric digits, while CPT codes are identified using five numeric digits.

Category III CPT Codes deal with emerging technology. The purpose of this category of codes is to facilitate data collection on and assessment of new services and procedures. Level 3 are the HCPCS modifiers. Only the HCPCS modifiers are maintained by the Alpha-Numeric Editorial Panel, consisting of the Health Insurance Association of America and the Blue Cross and Blue Shield Association. They are not included as being part of the use case.

The Health Care Financing Administration (HCFA) requires the use of CPT for reporting services to Medicare and Medicaid for reimbursement. In 2001, CPT was selected by the Department of Health and Human Services (HHS) as the standard code set for reporting health care services in electronic transactions.

1.4.1.1 Current state A patient is being referred by her PCP working in 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 - such as oncologists, general practitioners, 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). CPT codes are used to communicate laboratory and radiology orders placed in the CIS, and transmitted via HL7 interfaces to the LIS and RIS respectively. This requires that all systems using the CPT codes are up to date with the current value set of 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 the value set in multiple systems.

The laboratory personnel will use a common CPT code to record the examination of a cytology specimen. This information is further fed into the RIS system, as a code, but the RIS system has the different version of CPT. The information from both of these sources of information (laboratory and medical imaging) are fed into the Electronic Medical Record in order to create a discharge summary and to send the codes to the appropriate reimbursement organizations. Nevertheless, the EMR’s version of coding does not coincide with the one for LIS and RIS.

In addition, the EMR system needs to deal with changes in mandated coding systems. For example, the move from one Federal Medication Terminology (FMT) to another such as NDC to RxNorm.

The discharge summary is then published to a repository for healthcare facility B. The PCP can then retrieve it (via XDS, if both facility A and facility B are in the same affinity domain, or XCA, if cross-community access is available - alternative: the discharge summary is sent to the PCP via XDR or XDM). Two potentially undesirable cases can happen: either the billing information will not reach the provider, or the medical information is not exploitable and cannot be incorporated by the machines. If the coding is not uniform throughout 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. Worst yet, the flow of information in the hospital 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. If a summary is needed for the overall patient’s care or for public health, this will be lost. Even worst, 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 and errors in reimbursement error.

1.4.1.2 Desired state The hospital uses a Value Set Registry/Repository. Operational rules determine the update of a Value Set from the Value Set Repository and the Value Set Registry of the hospital, and a schedule for each system to query the Value Set Registry for possible updates. Another possibility is to have a system of notification so that the distribution of the nomenclature is synchronized throughout the applications. This allows for seamless updates, and reduces the risk of errors when updating individual systems. This way, the medical information and the billing information will flow seamlessly.

Of interest is to mention that the internal nomenclature used by the hospital must also be downloaded and synchronised with an external, official Terminology Server (having a similar Registry and Repository structure). For the scope of this use-case, this discussion is not included. Nevertheless, this is important since it will play a role in cross-community interactions.

1.4.2 Psychiatric coding using different systems

1.4.2.1 Current State In France, a patient is referred by his PCP to a university hospital for a psychiatric evaluation. The patient is diagnosed with a bipolar disorder. After his examination, the professor fills out an electronic form for the referring physician documenting the clinical encounter. The psychiatrist is using for coding DSM4 (Code system HL7 OID 2.16.840.1.113883.6.126), code 296.65 which describes Bipolar I Disorder, Most Recent Episode Mixed, In Partial Remission [1]. Using a translation code, he then codes as well using the ICD-10 Coding System, Chapter V: Mental and behavioral disorders (Code system HL7 OID 2.16.840.1.113883.6.3), code F31.6, which stands for Bipolar affective disorder, current episode mixed.

The discharge letter sent to one of the Affinity Domain’s repositories, from where the PCP can retrieve it. (This case assumes an XDS Affinity Domain, with a unique Registry, and multiple Repositories).

The family doctor has installed only ICD-10 catalogues in his software. He would like, nevertheless, to document the other type of code that the university professor has sent him, so that it would be processable by machines and integrated into an overall summary if need arises.

He does not have access to these values; hence he is obliged to leave the document as it is, and he is unable to transfer the additional coded information from the document to his own system.

1.4.2.2 Desired State The PCP’s application, which is capable of keeping track of multiple encodings, will be able to query a Value Set Repository and eventually obtain the Value Set extracted from DSM4. The coded information is integrated in the PCP’s documentation system and can be exploited by the PCP’s application.

21.3.3 HCPs Nomenclature Tables’ Update 21.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… 21.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.

Return to ITI Technical Committee