Stream: terminology
Topic: Alternatives to URI for system
Grahame Grieve (Jun 15 2017 at 01:38):
the FHIR terminology services work really well for FHIR content. They work less well if you want to use the terminology services with v2, CDA, or openEHR.
Grahame Grieve (Jun 15 2017 at 01:38):
the fundamental issue for all these is that they don't use URIs for representing code system identifiers
Grahame Grieve (Jun 15 2017 at 01:38):
CDA kind of does, in that it uses OIDs (which can be prefixed in a URI), but it's not the same URI.
Grahame Grieve (Jun 15 2017 at 01:39):
V2 uses a fixed string identifier (mostly) . So does openEHR. A different fixed identifier, of course.
Grahame Grieve (Jun 15 2017 at 01:39):
I'm interested in opinions as to what we should do to make the terminology services work really well in those contexts ?
Grahame Grieve (Jun 15 2017 at 01:39):
straw man idea:
Grahame Grieve (Jun 15 2017 at 01:41):
- define an extension for CDA, v2, and openEHR identifier on code systems.
- update the terminology services so that they accept these in coding.system from the client in place of the right FHIR URIs
- also, to return those extensions, if the client requests those identifiers
Grahame Grieve (Jun 15 2017 at 01:41):
thoughts?
John Moehrke (Jun 15 2017 at 13:11):
I tried to come up with a deterministic way when working on the IHE profiles. We decided to just warn the implementers that in some cases a lookup-table would be needed. Yes, it would be nice if the FHIR terminology services allowed for a list of alias (0..*). These would be searchable, but marked only for use when URI is not possible. Yes, please... and then I can update the IHE text...
Bryn Rhodes (Jun 19 2017 at 17:36):
So the URI in coding.system on a request in this case would be the URL of the CDS, v2, or openEHR extension?
Grahame Grieve (Jun 19 2017 at 21:13):
not a url? I don't actually know.
Last updated: Apr 12 2022 at 19:14 UTC