May 21

From IHE Wiki
Jump to navigation Jump to search

May 21 QRPH Face-to-Face Meeting Minutes

Agenda

  • Floyd Eisenberg (Siemens)
  • Jason Colquitt (Greenway Medical Systems)
  • Dan Levy (Outcomes Research)
  • Landen Bain (CDISC)
  • Harry Solomon (GE)
  • Daemon Whittenberg (Greenway Medical Systems)
  • Jacob Reider (Misys)
  • Joann Larson (Kaiser)
  • Penelope Solis (American Heart Association)
  • Ana Estelrich (GIP-DMP)
  • Patty Craig (The Joint Commission)
  • Vassil Peytchev (Epic)
  • Thom Kuhn (ACP)
  • Chad Bennett (IFMC)

The white paper will describe the sample value sets for the different measures and refer directly to the SVS profile and explain how the value sets can be represented using the SVS data structures. The Collaborative work will be discussed with respect to beneficial and challenging aspects and how the SVS value sets can be incorporated directly into the XML of the Collaborative.

SVS profile – retrieval of data sets from any repository and versioning.

Collaborative Schema Concerns:

  1. Continuous variables (means, medians for a population)
  2. Representing logic
  3. Looping conditions

RIM derived structures

Update Excel Spreadsheet of the Joint Commission measures with respect to data elements and value sets: Table was updated collaboratively. Specific highlights:

  • The ACEI and ARB Prescribed at Discharge was problematic with respect to data available in the CCD since the CCD discharge summary indicating “active” medication does not necessarily signify that the medication was prescribed at discharge. Therefore, the PCC Technical framework was checked for indication of prescribed medication. The XDS-MS indicates “The <consumable> element shall be present, and shall contain a <manufacturedProduct> entry conforming to the Product Entry template.”
  • The Product Entry contains manufacturedProduct/administerableMaterial.

The question came why do we have administrerableMaterial rather then having labeleddrug. In CCD we have labeleddrug and in PCC administerableMaterial.

Patty went down the list and explained the cross-walking. The comfort measures were discussed. Were comfort measures applied within the first day or the second day.

If we look at CCD do we just look at the last one, and even in the Discharge Summary how can you be sure that you are looking at the last one? The assumption is that when a Discharge Summary is signed that is a trigger for a measurement.

Can we assume that the vendor’s summary will pull the appropriate allergy from the system? Do we make the statement that this is the way we want to go? Because of these issues we will make the statement: “Do we enable the fact that they are multiple times or that there should be up to date every time”. As a hospital there should be updated each time.

The white paper will give the structure and the content. From a workflow perspective it would make more sense. If you use QRDA it might be more accurate exploring the longitudinal record, but it might be more difficult to specify its implementations. Using the Discharge Summary it would be easier. This is only specifying the structure for the input.

Can I use this for a concurrent way for decision support? This would need to be a measure in a structured document. If you provide the structure and the content, decision support. The contraindication it needs to be back to CCD. The patient is allergic and/or intolerant to Class A, B. How do you make the difference between the two? Harry will look it up, but it would be a better place to look it up in the PCC.

Methods for definition of value sets:

    1. Intensional definition of a value set: Represent a head concept (superordinate) code (e.g., ACEI allergy=SNOMED 2935000009). In this case, the measure developer’s specification includes the definition of the head concept and instructions the system tools resolve the set of subordinate codes at run time within the EHRS. (Example provide is the Allergy or Intolerance contraindication to ACEI value set).
    2. Explicitly represents a flat list of all matching codes derived from a head concept code and its subordinates (e.g., ACEI allergy SNOMED 2935000009 and its subordinates). (Example provide is the Allergy or Intolerance contraindication to ACEI value set).

Contraindication –

  1. Allergy or Intolerance – A value set may be defined in two methods:
    1. Intensional definition of a value set: Represent a head concept (superordinate) code (e.g., ACEI allergy=SNOMED 2935000009). In this case, the measure developer’s specification includes the definition of the head concept and instructions the system tools resolve the set of subordinate codes at run time within the EHRS.
    2. Explicitly represents a flat list of all matching codes derived from a head concept code and its subordinates (e.g., ACEI allergy SNOMED 2935000009 and its subordinates).
  2. Moderate to severe aortic stenosis is a contraindication for the ACEI / ARB administration measures (AMI3, HF3). There is a specific set of terms in the measure specification to represent moderate to severe aortic stenosis. SNOMED codes are available for:
  3. 427515002 – Critical stenosis of the aortic valve
  4. 60573004 – Aortic valve stenosis

Qualifiers:

  1. 24484000 – Severe
  2. 371924009 – Moderate to severe
  3. 6736007 – Moderate

Since value sets can be re-used, it seems prudent that the contraindication be represented by specifying a value set for “Aortic Value Stenosis” and a second value set for “Moderate to Severe”. The specification, then would need an observational construct that includes a primary finding from the aortic stenosis value set and a severity qualifier from the moderate to severe value set, or an observation primary code which is precoordinated as “Critical stenosis of the aortic valve.”

Other: - At some point there are diminishing returns from enhanced granularity of data expected by measure developers. A product of the need for logical expression of data aggregated in automated fashion data aggregation is the identification of the absence of data elements expected by the measure definition. In many cases, ambiguous statements cannot be mapped to explicitly defined data elements that exist in electronic health records. Examples include elements defined as contraindications such as hypotension which require the context of time, episode(s) of care, historical documentation, etc. The concept of defining medical or patient reason for exclusion from a measure is also not a specific element captured within a patient care flow. Patient care is not specific to measurement. Contraindications should represent elements identified as part of routine patient care flow. Modeling of clinical statements is difficult at best. There are multiple ways to represent any particular concept. i.

There is also reference that documentation of a history of moderate to severe aortic stenosis is also acceptable as long as there is no evidence of repair or commissurotomy.