Stream: australia
Topic: NCTS Data Components System URL
Brett Esler (May 08 2017 at 01:25):
Has anyone had any thoughts on a suitable system URL for NCTS Data Components as per CDA document section code like CDA IG
component[med_hist]/section/code
component[med_hist]/section/code/@code="101.16117"
component[med_hist]/section/code/@codeSystem="1.2.36.1.2001.1001.101"
component[med_hist]/section/code/@displayName="Medical History"
So a URL for OID 1.2.36.1.2001.1001.101?
Suggest something in http://ns.electronichealth.net.au space like http://ns.electronichealth.net.au/clinical-information/data-component to borrow from the OID registered ASN.1 notation?
Richard Townley-O'Neill (May 08 2017 at 01:32):
http://ns.electronichealth.net.au/ci/dc is already published. But, it is very terse and, as Brett says, does not follow the registered ASN.1 notation.
I like ...clinical-information/data-component
Stephen Royce (May 08 2017 at 02:07):
Terse is good!! You can follow the URL to get information about the namespace if it's not clear. I suggest we continue to use it as published.
Stephen Royce (May 08 2017 at 02:35):
By the way, the codes used in CDA are actually compound codes. In @Brett Esler's example the code has 2 parts: "101" which means "Section" and "16117" which means "Medical History", i.e. this is the code for the Medical History section. In the case of Medical History, the concept is unique, but we have many data components for which the name/code is not unique, thus requiring the data component type as a differentiator. This means, that the purist way of representing these codes would be fuller URLs and shorter codes -- http://ns.electronichealth.net.au/ci/dc/sctn as the URL & "16117" as the code in this example. Is there any appetite for doing this "properly?" Perhaps it would be too hard anyway because you'd have to have smarter code if you were working with both CDA and FHIR?
Brett Esler (May 08 2017 at 03:33):
I'd be happy with the 'terse' url just looking for advice on that one... who gets to make the call on that one? The terse one has been published so it resolves so has that advantage for sure...
As for multipart - is there reuse of the 16117 code in other contexts than sections?
Stephen Royce (May 08 2017 at 05:04):
Re "is there reuse of the 16117 code in other contexts than sections?" Not in this particular case, but there certainly can be. You cannot use 16117 on it's own; you either have to use a different URL (like the one I suggested) or use "101.16117" as the code.
Brett Esler (May 08 2017 at 05:10):
I like "101.16117" as a code; but I don't really have a good reason other than it matches the CDA IGs... why would I do the other?
Stephen Royce (May 08 2017 at 08:27):
From a purist perspective, it's more correct. The codes are actually the tail arcs of OIDs and so it would be more proper to use a namespace equivalent, in this case to the 1.2.36.1.2001.1001.101.101 OID and just use the final arc - 16117 as the code.
Stephen Royce (May 08 2017 at 08:30):
We didn't do it for CDA because it was felt that it would be too confusing for the community at the time (circa 2009/10) and, more importantly, the CI team didn't have the resources to support more than 1 value set externally. (We could do internally easily enough, but not publicly.)
Stephen Royce (May 08 2017 at 08:32):
I think there may still be some weight to the first reason, although hopefully not much these days, but not the 2nd. CI can easily expose all this via proper FHIR ValueSets now.
Last updated: Apr 12 2022 at 19:14 UTC
