Data Usability Workgroup

Specific Domain Guidance for Usability

  • This topic has 3 replies, 1 voice, and was last updated 1 year ago by Tom Bronken.
Viewing 3 reply threads
  • Author
    • #33466 Reply
      Hera Ashraf

      We send different types of documents in different clinical scenarios. These different documents contain different types and quantities of information. For instance, in a clinical summary we might only include labs that were resulted within a certain time frame. 

      Reply to this post with your answers to these questions:
      1. Have you encountered ‘gaps’ in information received in which a standard minimum amount of information would be useful? 
      2. Are there situations you’ve noticed where excessive information is included in a document and summarized data  would be more useful? For instance, averaged or summarized vitals measurements for an inpatient stay, or admission and discharge labs?

    • #34596 Reply
      Riki Merrick

      When discussing summarizing data it is important to know that you are comparing apples to apples – so SHIELD (Systemic Harmonization and Interoperability Enhancement for Laboratory Data) is a public provate partnership that is working on a strategic plan with the goal to “Name the same test the same way across the healthcare continuum” – this group is tackling the difficult problem of making sure lab results from differnt performers / vendors / instruments can be compared without the risk to patient safety.

    • #36073 Reply
      Andrea Pitkus

      One of the challenges SHIELD faces is naming conventions. One cannot tell the full meaning of the lab test by it’s name alone. Other info like specimen, units, method, etc are needed for the full meaning of a test.

      As delineated in the Sequoia lab google sheets, the same test name may be used by different labs and EHRs (i.e. CBC) and mean different things if one has a platelet count and another doesn’t. To riki’s point these would be comparing a full apple to one with a slice removed.

      Another aspect in your use of document, it appears this may include paper records. Is that correct? If so, paper/fax/phone results lack coding providing additional clarification on meaning.

      Lastly, and one of the most important, is most all EHRs do not preserve the performing laboratory’s naming conventions. Rather, they use a more generic version of the test as preferred by clinicians in their EHR use. See Sequoia lab examples in google sheets. When the exact same test from a laboratory is named differently across EHR vendors, physician practices, etc due to their build preferences, and then shared across HIEs, with public health and other providers, how will the receiver know it’s the exact same test they received and they are the same, when they are named differently? This contributes greatly to usability issues with the variety seen nationally.

      That said, I understand many providers have a notion in their mind of what each test “is” meaning-wise. They may not be interested in differences of methodology, specimen, etc that can impact result values or may not be aware of said impacts to their clinical decision making.

      It’s also an informatics build issue. Some lab results are built once (i.e. Wound Culture) with the specimen source indicated in another field. No physician wants to scroll through 200+ precoordinated culture terms such as Wound Culture left big toe, Wound culture right pinky finger to find the site on the body they are culturing. No laboratory would want to build and maintain 200+ more tests in their lab menus either. So there are practicality issues too.

    • #48035 Reply
      Tom Bronken

      Regardless of the domain under consideration, organizing the data for overall appreciation and then subsequent drill-down is vital. That requires a set of agreed upon organizing principles on both the sending and the receiving end of the data exchange. The first criterion is to have an agreed upon coding convention. The second criterion is to have an agreed upon hierarchical taxonomy of those coded terms. With the exception of Snomed-CT for problems, that is generally lacking.

      This has been discussed previously with regard to laboratory results. Two other domains that are in sore need of this kind of rigor are medications and documents. While recognizing that some medications may be indicated in more than once circumstance, agreeing on an organization of specific RxNorm codes by condition treated would greatly simplify medication reconciliation.

      With regard to documents, there is an ever-expanding system of LOINC codes for documents, but some vendors are hesitant to use anything except the codes for a Summary of Episode note (aka, the CCD) and a generic Progress note. Receiving vendors often do not identify these notes, when received, by the LOINC code naming conventions, but instead by the idiosyncratic titles put on them by the sending organization. Finding the document of interest is very difficult. How much better would it be if all vendors used specific LOINC codes on their documents, and if all LOINC codes were listed by an agreed upon naming convention like LOINC, and grouped into an agreed upon hierarchy (or multi-axial hierarchy) that could be used to organize, sort, filter, and search?

Viewing 3 reply threads
Reply To: Specific Domain Guidance for Usability
Your information:

Skip to toolbar