After a couple of months of slacking off (you know, doing stuff like HL7 Ballots, going to the working group meeting, IHE Connectathon, and Radiology workgoup meetings), PCC members are preparing for our meeting in Paris.
I think I have four things on my plate, one of which is workflow, the other deals with CDS for Radiology, one supports existing Continua work I helped out with a half-decade ago, and the last of which is integrating clinical devices with an EHR.
We had our first call for a while on the Device Clinical Bridge work that PCC agreed to do. The work on the device clinical bridge really amounts to how we can adapt a PCD-01 inbound message to terminology that supports EHR adoption. When you get right down to it, the biggest challenge is the terminology mapping.
For the bridging work requested for this profile, the challenge is to convert PCD-01 messages using IEEE nomenclature (so-called MDC codes) into equivalents using LOINC, that being the preferred vocabulary for certain kinds of measurement under Meaningful Use. In other cases, we could see the need to translate from ICD-9-CM codes to ICD-10-CM, or from SNOMED-CT to ICD or vice verse. There are also cases where you might need to translate from NDC to RX-Norm, or again, vice verse. You might also use such a facility to translate from local codes to standardized code sets.
From an actor/transaction perspective, I see
In looking at the available standards, I found three possible candidates:
In addition, a simple extension to IHE SVS could also have supported the required capability for the Device Clinical Bridge, but would likely have been insufficient for other uses.
In looking over these specifications, I came to the following conclusions:
I can pretty much rule out CTS1 for a number of reasons, including the fact that it doesn't fully support the requirements. We'll have to look at CTS2 and FHIR's ConceptMap. Honestly, CTS2 suffers tremendously from over-engineering, and while we could profile it down to something reasonable, I'm just not convinced that it would be readily adopted. FHIR is in much better shape, but we would be waiting for the next DSTU release for this operation. There's a little bit missing here, in that the context (dependson) for the mapping cannot be specified in the operation. A little tweak is all that is needed to make that work.
This is especially needed to handle concept mapping from IEEE codes where the units are necessary to fully specify the resulting LOINC code in the principle use case. I can also see other cases where additional concepts might be necessary for ICD-9-CM to ICD-10-CM, or in other mappings.
Keith
I think I have four things on my plate, one of which is workflow, the other deals with CDS for Radiology, one supports existing Continua work I helped out with a half-decade ago, and the last of which is integrating clinical devices with an EHR.
We had our first call for a while on the Device Clinical Bridge work that PCC agreed to do. The work on the device clinical bridge really amounts to how we can adapt a PCD-01 inbound message to terminology that supports EHR adoption. When you get right down to it, the biggest challenge is the terminology mapping.
For the bridging work requested for this profile, the challenge is to convert PCD-01 messages using IEEE nomenclature (so-called MDC codes) into equivalents using LOINC, that being the preferred vocabulary for certain kinds of measurement under Meaningful Use. In other cases, we could see the need to translate from ICD-9-CM codes to ICD-10-CM, or from SNOMED-CT to ICD or vice verse. There are also cases where you might need to translate from NDC to RX-Norm, or again, vice verse. You might also use such a facility to translate from local codes to standardized code sets.
From an actor/transaction perspective, I see
In looking at the available standards, I found three possible candidates:
- HL7 Common Terminology Services Release 1
- HL7 + OMG Common Terminology Services Release 2
- HL7 FHIR ConceptMap Resource
In addition, a simple extension to IHE SVS could also have supported the required capability for the Device Clinical Bridge, but would likely have been insufficient for other uses.
In looking over these specifications, I came to the following conclusions:
- CTS Release 1 doesn't readily support all the mapping requirements, and has also been replaced by CTS2.
- CTS Release 2 does support the mapping requirements, but implementing it would be a bitch.
- The current FHIR ConceptMap resource supports what is needed. but the translate operation isn't quite there yet.
I can pretty much rule out CTS1 for a number of reasons, including the fact that it doesn't fully support the requirements. We'll have to look at CTS2 and FHIR's ConceptMap. Honestly, CTS2 suffers tremendously from over-engineering, and while we could profile it down to something reasonable, I'm just not convinced that it would be readily adopted. FHIR is in much better shape, but we would be waiting for the next DSTU release for this operation. There's a little bit missing here, in that the context (dependson) for the mapping cannot be specified in the operation. A little tweak is all that is needed to make that work.
This is especially needed to handle concept mapping from IEEE codes where the units are necessary to fully specify the resulting LOINC code in the principle use case. I can also see other cases where additional concepts might be necessary for ICD-9-CM to ICD-10-CM, or in other mappings.
Keith
Have you submitted the change request? ("Request a change link" at the bottom of each page.) Final content for DSTU 2 is due Mar. 22nd, so getting it in soon would be good.
ReplyDeleteAwaiting a reset on my GForge account
ReplyDelete