CCD Suggested Enhancements

SDWG page.

NOTE: Membership on this list bestows no special privileges. The list is just a convenient catalog of various comments received along the way. Each of these suggested enhancements will need use case backing, a formal proposal, etc before being considered for CCD Release 2. There is no requirement that an item be on this list to be considered for CCD Release 2.

CCD Suggested Enhancements

• Currently, vital signs reuse the results template, which states that reference range and interpretation code SHOULD be present. Vital signs don't typically include reference range and interpretation code. Suggest creating a broader template for vital signs, where reference range and interpretation code have a MAY constraint. The result template can be a specialization of the vital signs template.

Use of Detailed Clinical Models (DCM)

One of the features which emerged from CCD r1 was the ability to reference and re-use existing work. This has been limited because:

• The initial scope and time did not allow for comprehensive modeling and
• There isn't a mechanism for updating only part of an CDA

This is one (of many) driving factors for the notion of having a repository of versioned DCMs. A given CCD instance could use a static (similar to what we now think of as normative) reference to a specific version, or it could also use whatever happened to be the current (or best flavored) version.

The publication/distribution/download format has not been decided, AFAIK, but it presumably would be in whatever format we determine is the optimal way to distribute computable constraints (e.g. XPath--useful for data extraction, user interface controls, e.g. XForms, or validation/business rules with Schematron) from some ISO 11179 MDR.

By externalizing the definition of the content from the actual CCD specification we would make it much easier for reuse, as the various models could be indexed (a very good reason to retain Observation.code!), classified, and duplicates harmonized (another good reason to use Observation.code). This is a rather good information practice in general.

The other advantage is that DCMs should gracefully handle different levels of detail. While all the detail for a completely SNOMED-CT encoded comprehensive sub-specialist contribution, the same model should be able to also convey the subset used by various specialties.

Inclusion of Criteria Based Severity Scales

We are all familiar with the various interpretations of "moderate", and most recognize that "moderate septic shock" is quite different in overall severity from "moderate sunburn". There are a host of criteria based severity indexes for nearly every condition under the sun. They are, however, difficult to locate and implement at the time of care. CCD could greatly simplify this by including references to them in the implementation guide, providing a common implementation of a critical subset of these (preferably those which are available w/o having to first license the scale). This could go a long way to improving the comparability of clinical data.

Common Toxicity Criteria for Adverse Events (CTCAE)

One criteria based system which is widely used in clinical research (particularly oncology, but in many pharmaceutical studies in general) is CTCAE 4. It provides grades which are reasonably approximate across clinical disorders, such that a "grade 3" finding means "Severe or medically significant but not immediately life-threatening; hospitalization or prolongation of hospitalization indicated; disabling; limiting self care ADL" and "grade 5" is dead. While not perfect, there is a good deal of experience and content. Further work is needed to determine clinical applicability, but provision for CTCAE findings, or similar, along with the somewhat object severity (e.g. using the SNOMED-CT Severity 246112005|Severity (attribute)) provided in a SNOMED-CT expression should be anticipated.

Inclusion of Clinical Trial Participation

While only a minority of patients are involved in a clinical trial, it is very important to alert the caregivers of those individual. The research team may have additional information, be able to identify what the individual is taking in case of emergency, and has an obligation to record and report possible adverse effects. This should include the identity and contact information of the principle investigator or study site investigator who is monitoring them, as well as any emergency contacts, the IND number (if applicable), the title of the protocol, and links to further information (e.g. SOPs for evaluation of anticipated problems, description of study intervention, link to the entry in clinicaltrials.gov, etc.) provided.

Harmonization and Collaboration with Disease and System Registries

Harmonization with Data Elements for Emergency Department Systems (DEEDS) and National EMS Information Systems (NEMSIS) updates

As part of the DEEDS update and revision efforts, data elements in common with the CDA H&P and CCD have been identified. Furthermore, there is obvious commonality with NEMSIS work at HL7 as well. This is an area where having common models would be of obvious and immediate benefit to those who have the least opportunity to convey health information.

Harmonization with Cancer Registries

Currently there are many involved and active cancer registries, including NAACCR, the Centers for Disease Control and Prevention (CDC) , the National Cancer Institute's (NCI) Surveillance Epidemiology and End Results (SEER) program, and National Comprehensive Cancer Network (NCCN). These organizations and the data they collect is instrumental in finding optimal care for what is essentially a disease of information processing dysfunction.

Clear Indication of Differential Diagnosis and Incomplete Evaluations

This is where the ball gets dropped.

Improved functionality of Problem List (aka Health Concern topic)

It is most unfortunate that this is called a list. It is not. It is more complicated than an ordered sequence, although it does make use of such. The core components must include:

• Provide type/application context specific "close to user" labels. This is what most people think of when they talk about problem lists. This is a mechanism to help organize the information:
  • For tracking over time. This is very similar to the Weedian notion of the problem oriented medical record.
  • Work flow. In the US, a problem / diagnosis / reason is required for diagnostic studies to assure proper insurance coverage. This provides a patient specific set of options.
  • Graphic displays
  • Association with elements in a care plan
• Provides a linkage between encounters and the topic / subject. This is an "under the hood" function of EHRS software, but the information in the CCD should support this.
• Group clinical findings (positive, negative, quantitative/measured, assessment scales, coded clinical findings) under a heading for the purpose of explanation, diagnosis, and analysis
  • This should allow viewing all of the various instances of "finding X" in the record (e.g. find the specific finding/diagnosis of headaches in a person who has a problem / concern of "frequent headaches"
• Exposing and tracking specific medication related issues. For example, anyone who is successfully treated with Warfarin has an acquired bleeding diathesis.
• Showing the temporal sequence and evolution / response to therapy of a disorder
• Aggregating various findings / components under a common heading. For example, dyspnea on exertion (DOE) and dependent edema could be lumped together under some heading of "features possibly suggesting congestive heart failure". Subsequent evaluation may show a creatinine of 6, Kerley B lines and "plump" central venous structures, diastolic blood pressure of 118, and a hyper-trophic heart with an ejection fraction of 41%. The prior "problem" would be replaced with "diastolic dysfunction with pulmonary edema and renal failure".
  • The relationship between the various findings over time needs to be tracked by EHRS/PHRS software, but the data needs to be present in a fashion which allows such.
  • The temporal sequence of events, and the replacement of one "label" (aka "diagnosis" or "problem").
  • Multiple membership is common. The patient may also be a 80+ pack-year smoker with asthma. Their problem of "dyspnea" would have multiple underlying causes, just as diabetes would be a possible etiology of CRI/ESRD.

'This is undoubtedly the heart and soul of the CCD.

• While the actual "data" contained in the "problem list" is small (the various labels associated with the actual entries), there is a tremendous amount of linkage between Observations, Procedures, Substance Administrations, Events (Acts), etc.
  • Because of the complexity of this, it would be best to start small, and add in incremental updates (e.g. CCD r3.1, 3.2, etc.).
  • Links between problems/concerns and treatment regimes and between clinical findings and problems/concerns would seem a useful "sweet spot" to start with for evaluation and testing.

--KevinCoonanMD 00:54, 10 May 2010 (UTC)

Improvements to the generic XSLT

The "Mayo/Tyylitiedosto" CCD XSLT transformation has become a very common unofficial standard XSLT transformation for CCDs. This file is not formally maintained, perhaps it should be.

Some issues/enhancements to get started:

• Nowhere to submit bugs or enhancements
• XSLT fails if given @StyleCode attributes which are not Bold, Italics, or Underline (see: http://stackoverflow.com/questions/12624855/xslt-checking-for-an-attribute-how-do-i-make-it-do-nothing-if-that-attribute/)
• This XSLT is not licensed. Having no license is worse than a restrictive license, users don't know what their obligations are when using, distributing or modifying this file
• The XSLT is testable, given a CCD ensure that certain HTML is produced. A project might help organize this and properly maintain the transformation.
• The XSLT is very reliant on the Narrative Block, perhaps it could be improved to use the coded information in the CCD to augment the narrative text