Forum Replies Created

I must offer the caution that there are of course lots of important changes in each release (deprecated terms, edits, etc) that are contained in each release, so just looking at new terms added may not be what you need. That being said, the easiest way to find them would be just to run a query between the LOINC table from 2.40 and 2.42. Here’s how you might do it if you are using Microsoft Access:

Link the tables on the LOINC_NUM field, right click the relationship, and choose Join Properties of “Include ALL records from”…of the LOINC 2.42 table. Then just put both LOINC_NUM fields (and whatever else you want) in your query and indicate the LOINC_NUM field for LOINC 2.40 to be “Is Null”:

That’ll give you this result, which is the 775 as indicated in the release notes

We would certainly encourage the construction of local use-case specific hierarchies based on whatever roll-ups you felt necessary. For that you could use the LOINC parts or the strings to do it (e.g. anything with a component of “Admission Evaluation Note”). We also have a recently implemented policy about creating a “generic” term wherever we have document terms that specify a setting or provider. This generic term could be used as a generic parent for the more specific types. E.g. this term:

We don’t recommend using the Part codes directly as a “observable” concept code because they don’t have the same change management principles applied (e.g. deprecation, concept permanence, etc) as the LOINC codes do. They have several purposes…some internal.

There is no registration fee and I don’t believe that there is any restriction on who can attend other than that you’ll have to create an account on the Sysmex website (they are hosting it). When I registered on their site, I believe the “country” list is limited to a subset of North American countries (presumably their market area), but Canada is there, so I’d say invite away!

From within RELMA, just search for the panel term you want. Right click the row, then choose “View Panel Children”. That will pop up a window with all the child elements of the panel in a grid. From there you can select all the rows, choose Custom Export to get all the LOINCs in a variety of formats (copy to clipboard, export to excel, etc).

You may also want to check out the LOINC Panel’s and Forms File under Accessory Files from http://loinc.org/downloads for an export of some of the key panels and forms.

Yes, you can use the CLASS field of the LOINC database for exactly this purpose. Take a look at Appendix B of the LOINC User’s Guide for a detailed listing of the classes. If you are using RELMA, you can restrict your searches to any particular class (or any other hierarchy node) by going over to the “hierarchy and search restrictions” tab and selecting the node at which you want to limit your search.

The upcoming RELMA release (5.0) will have a way to do this from the search command line, so stay tuned…

You are correct in that not all LOINC codes are present in the multiaxial hierarchy. It includes lab, radiology, clinical note titles, and some other clinical variables, but not the whole database. So it is not a matter of syncing, but rather the scope of content included in the multi-axial hierarchy to date. This is largely a matter of focus and resources; we don’t have a defined plan for adding all LOINCs to this hierarchy. The other hierarchies are stored in the database that the RELMA program uses, but that is available for direct use only under specific permission from Regenstrief (see http://loinc.org/terms-of-use). Those hierarchies are not in the same format as the multi-axial export and could change over time (because they are used by RELMA). We have discussed exporting all the hierarchies in the same format as the multiaxial one, but haven’t nailed that down yet. Is that something you would use?

The short answer is that there is no ‘right’ answer for all circumstances.

Historically, we (LOINC) have recommended the use of the ShortName (over the colon-separated fully-specified name) in HL7 messages because it fit within the space allocated by most lab reporting systems (30 characters), would work as a column name on a flowsheet, and used common acronyms people would recognize. I think the fully specified name has more instances of ‘reserved characters’ like “^” and “&” which would need to be properly escaped, and we’ve heard a few folks mention difficulty with their systems doing this…though there is a clear cut way to do it.The base HL7 2.x standard doesn’t specify (and actually would be valid if you sent your own label as the display name associated with a LOINC code — something we don’t recommend). More recently we developed (and now have fully-populated) a Long Common Name. These are probably more understandable to human readers and might be preferable, but they can be quite long, so some systems may not accomodate. The HL7 implementation guides for certain use cases (e.g. ELR to public health) may or may not constrain the freedom of the base standard with respect to the preferred display name, thus leaving the choice up to the exchanging partners. This has also come up in the recent EHR certification testing specs, and we have made comments to NIST about it. This display name issue is being discussed as a project in the HL7 vocab workgroup because it is not unique to LOINC.

So, if there are no other constraints, I’d recommend the Long Common Name, but the Short Name or Fully-specified Name are valid in most contexts too. Since the Long Common Name has only recently reached a state of moderate maturity, we haven’t yet updated the LOINC Users’ Guide, but we probably will revise it to include a summary of the above sometime in the near future. We also definitely recommend the simultaneous messaging of the senders local code and local name (in addition to the LOINC code and Name) to facilitate debugging and detection of mis-mappings.

We populate the ORDERS_OBSERVATION field for all lab terms in the database. The Common Lab Orders value set is purposely a short set of codes that account for the vast majority of lab orders in the US. It was derived by both empirical and consensus-based approaches. You should consider it a minimun “starter set” and definitely doesn’t include all possible LOINC codes or lab orders. You can read more about how it was derived in the Preface, which you can get from:

This field is our best (informed guess) as to whether this LOINC code can be used as an Order code (e.g. in an OBR segment) and Observation code (e.g. in an OBX segment), or Both. Many terms can be used as both, panel terms will Order only, and things like calculations or impressions will typically be Observations (you can’t order them directly).

In follow-up to the February 2010 Clinical LOINC Meeting a new spreadsheet has been generated to show the proposed changes to the existing LOINC terms with all axis value changes (part level changes) aggregated at a per-term level. It is available in the Doc Ontology section of the LOINC website:

The first sheet titled “Proposed Changes” is any changes in current terms. Green (light) – Proposed changes Green (dark) – Proposed new term to reconcile/disambiguate changes Yellow – Document Ontology axis value “fragment” that is the source of discussion for reconciliation to the new model. The “Disposition” column is the (highest) classification of the existing LOINC change depending on our review of the changes to the axis values. The “Comments” column includes comments from Dan and Blaine. The second spreadsheet lists the fragments with no significant changes.

We’ll try to plan a call to discuss these changes in advance of the next Clinical LOINC meeting.

Yes, the panel/form structure is available as a separate download, but not every panel is contained there. We started with a key subset to get feedback on the file structure/format. We’d be happy to take suggestions on additional content you’d like to see included (e.g. all panels?) and whether you have suggestions about the file format.

The file is called “LOINC Panels and Forms File” and it is available as one of the Accessory Files in the LOINC distribution from the LOINC Downloads page:

An export of a key subset of the Panels and Forms represented in LOINC. The entire package of this key subset is currently available, in addition to separate packages for Consumer Health panels and forms, HEDIS 2009 panels, the HL7 Clinical Genetics panels, Newborn Screening panels, US Government panels and forms (including the CMS survey instruments MDSv2, MDSv3, OASIS, and CARE), and Other Survey Instruments. The hierarchical structure is represented in the file by the PARENT_ID, ID and SEQUENCE fields. The root, or top level, records in the file are those records where the PARENT_ID = ID. The records are in a Microsoft Excel spreadsheet (compressed as a zip file) with separate worksheets (tabs) for the form structure, loinc code details, and answer lists.

We do not have an Arabic language translation of LOINC yet. About a two years ago we had some contact with an Egyptian physician who expressed interest in doing an Arabic translation, but we have not heard back from him. If you are interesting in doing or organizing a translation, let us know and we’d be happy to point you in the right direction.