Everybody likes to talk about how necessary refsets are, but I’m not sure if the reason why is always known. One of the challenges facing implementers is how might they use what’s available and what else might they actually need?
So here’s what I think are two fundamental use cases – Exchange and Interface.
And for the purposes of this article when I say ‘refset’ – I just mean a subset of SNOMED CT.
In any messaging scenario – either to an intermediate repository or directly to the recipient – the structured messages (HL7v2, CDA etc.) require certain codes to go in certain fields. Some code systems express these constraints as basic tables. In SNOMED CT the simplest* (standardised) way to express a subset is by using a Simple type refset.
For example we might constrain acceptable values for a Diagnosis field to subtypes of 404684003|Clinical finding (finding)|.
The reason for this is that if a document author has the choice of all 300K+ concepts in SNOMED CT, and they want to record an instance of Staph Infection… There’s a risk they might select 65119002|Staphylococcus|, when the intention is really 56038003|Staphylococcal infectious disease|. The first concept is a actually from the ‘organism’ hierarchy; ie. Not a diagnosis! This difference might not be obvious to front line medical staff whose job doesn’t revolve around understanding terminologies.
When these constraints are clearly articulated, they can be used to validate the documents. So the audience for these refsets is really:
- Developers who want to comply with standard specifications; and
- Testers checking for conformance to standard specifications.
But NOT Clinicians.
Note! When using just a Simple type refset to express these constraints, the use of ANY post-coordinated expressions is immediately prohibited. Ideally, messaging constraints should be expressed as intensional refsets…
So a clinician now has some constraints on what they might pick for a diagnoses. However, there’s still a choice of at least 90,000+ clinical findings…
Depending on how much effort their software vendor puts into search functionality, having all these in a drop down box is going to lead to a pretty poor user experience. And not every interface uses dropdowns… Maybe radio buttons, check boxes or any other sort of UI control. And depending on the user’s expectations of the software, it’s probably they won’t want noise – concepts they’d never pick.
It’s unlikely a:
- Gynaecologist will need to record a 92428008|Benign neoplasm of testis (disorder)| diagnoses; or
- Radiographer is going to bill for performing a 12845003|Malaria smear (procedure)|; or
- Pharmacist will dispense an Extemporaneous preparation with 227036006 | Luncheon meat (substance)| as an active ingredient.
Putting “search solutions” aside, terminology implementation at the interface is may require subsets of the exchange subsets.
There’s nothing stopping software vendors creating these subsets for their own software/customers. But the challenge from a national (or even international) perspective is – What might you be able to provide to encourage adoption and where might you start?
A common call is for a ‘Top 100’ refset… For example a “GP 100” But what does this mean?
- Who’s 100? A GP Registrar in Alice Springs or a private GP in Toorak, Melbourne?
- 100 What? Diagnoses, Procedures, Prescribables, Reasons for encounter?
- What about things not in the 100? Free text? Choose “something close”?
I’m not dismissing the “Top 100” idea, but I think it’s purpose needs to be defined. For me, I think the Top 100 should represent a ‘starter’ refset.
- Implementers can add/remove from it as they see fit.
- Users may search beyond the 100+ if they need to.
There’s not necessarily any requirement to use a Top100. It might make things easier, but it should be up the software developer – to satisfy the interests of their customers.
The only requirement of a Top100, and any customisation of such, is that it MUST be a subset of an Exchange refset.
The provision of such “Starter refsets” needn’t come with any guarantees. If a developer chooses to customise the refset to their design; after the initial creation there doesn’t need to be any ongoing relationship to the “Starter”. Any changes are at their discretion – so long as their messages continue to conform to the Exchange refset.
What about the recipient?
Does it matter?
AFAIK, a document should be able to be rendered (for humans) by anybody, without even needing access to any terminology servers. Anybody can view a CDA document with their usual web browsers. Other message types might require specialised software, but all the information for a human to process the content – should be available in the document.
To do something smart like decision support or secondary analysis… that IS going to require some some work….