A few issues have arisen in the community regarding the “code
validation” use case. Currently, the FHIR “validate” query action returns,
essentially, a binary yes/no response. Could you please consider the questions
below and provide your recommendations? Cross-posted to the Architecture forum.
-
Should the validate query action also return the
basic identifiers ( name, code, description, etc.) of the matched concept (if any) for the entry concept/system pair?
-
Should the return of the basic identifiers be
part of a separate query action, say “lookup”, rather than part of the “validate”
action?
-
Should either of the above options support bulk
(more than one entry code) in the same transaction? Might this be helpful in the IL?
Thanks,
Jack
hi Jack
A few issues have arisen in the community regarding the “code validation”
use case. Currently, the FHIR “validate” query action returns, essentially,
a binary yes/no response.
Actually, this is what the current documentation says:
"The server returns a true/false indicating whether the code/concept is
valid, and a list of errors and warnings associated with it. The server
should also return all the display names that are associated with the
code as part of this operation."
Could you please consider the questions below and
provide your recommendations? Cross-posted to the Architecture forum.
Should the validate query action also return the basic identifiers ( name,
code, description, etc.) of the matched concept (if any) for the entry
concept/system pair?
well, what's the purpose? What is it that you want back? I can see
a use case - which isn't catered for yet - to say "well, my base concept
is {system}/{code} in some context. please tell me how to represent
this in an interoperable way (code, display, translations, versions).
is this what you want?
Should the return of the basic identifiers be part of a separate query
action, say “lookup”, rather than part of the “validate” action?
Should either of the above options support bulk (more than one entry code)
in the same transaction? Might this be helpful in the IL?
I haven't done bulk anything in the API, pretty much. What bulk stuff
would be used?
Grahame
Grahame,
The documentation regarding display names should cover it. I must be looking at the wrong page. There could be an issue of “display” names (what I might call synonyms) versus a fully-specified name (in SNOMED speak), but this may just be a difference in my understanding.
Regarding “bulk” validation, I’ll defer to the IL team. As I understood it, the issue was validation of a set of codes that were found in a CDA or other document. Faster to validate all of them at once than one at a time.
Jack
···
On Thursday, October 16, 2014 3:45:09 PM UTC-4, grahame wrote:
hi Jack
A few issues have arisen in the community regarding the “code validation”
use case. Currently, the FHIR “validate” query action returns, essentially,
a binary yes/no response.
Actually, this is what the current documentation says:
"The server returns a true/false indicating whether the code/concept is
valid, and a list of errors and warnings associated with it. The server
should also return all the display names that are associated with the
code as part of this operation."
Could you please consider the questions below and
provide your recommendations? Cross-posted to the Architecture forum.
Should the validate query action also return the basic identifiers ( name,
code, description, etc.) of the matched concept (if any) for the entry
concept/system pair?
well, what’s the purpose? What is it that you want back? I can see
a use case - which isn’t catered for yet - to say "well, my base concept
is {system}/{code} in some context. please tell me how to represent
this in an interoperable way (code, display, translations, versions).
is this what you want?
Should the return of the basic identifiers be part of a separate query
action, say “lookup”, rather than part of the “validate” action?
Should either of the above options support bulk (more than one entry code)
in the same transaction? Might this be helpful in the IL?
I haven’t done bulk anything in the API, pretty much. What bulk stuff
would be used?
Grahame
Cross-posting a response from Ryan Crichton on the Architecture forum:
Hi Jack,
Here is my take on these questions, others may have different views.
- I don’t think so as the validate query should be really fast as many of these calls may need to occur in a short amount of time (for example when validating all codes within a CDA document)
- That sounds like a good idea to me, then if more details are needed they can be explicitly fetched.
- This would be of value to the IL as we will likely need to validate a number of codes at once to validate all terminology in a single CDA document and this may have an efficiency benefit. However, this isn’t strictly required as the same could be accomplished with multiple calls to number 1, we would just gain some efficiency.
I hope this helps. I look forward to hearing others views.
Cheers,
Ryan
···
On Sunday, October 19, 2014 12:30:26 PM UTC-4, Jack Bowie wrote:
Grahame,
The documentation regarding display names should cover it. I must be looking at the wrong page. There could be an issue of “display” names (what I might call synonyms) versus a fully-specified name (in SNOMED speak), but this may just be a difference in my understanding.
Regarding “bulk” validation, I’ll defer to the IL team. As I understood it, the issue was validation of a set of codes that were found in a CDA or other document. Faster to validate all of them at once than one at a time.
Jack
On Thursday, October 16, 2014 3:45:09 PM UTC-4, grahame wrote:
hi Jack
A few issues have arisen in the community regarding the “code validation”
use case. Currently, the FHIR “validate” query action returns, essentially,
a binary yes/no response.
Actually, this is what the current documentation says:
"The server returns a true/false indicating whether the code/concept is
valid, and a list of errors and warnings associated with it. The server
should also return all the display names that are associated with the
code as part of this operation."
Could you please consider the questions below and
provide your recommendations? Cross-posted to the Architecture forum.
Should the validate query action also return the basic identifiers ( name,
code, description, etc.) of the matched concept (if any) for the entry
concept/system pair?
well, what’s the purpose? What is it that you want back? I can see
a use case - which isn’t catered for yet - to say "well, my base concept
is {system}/{code} in some context. please tell me how to represent
this in an interoperable way (code, display, translations, versions).
is this what you want?
Should the return of the basic identifiers be part of a separate query
action, say “lookup”, rather than part of the “validate” action?
Should either of the above options support bulk (more than one entry code)
in the same transaction? Might this be helpful in the IL?
I haven’t done bulk anything in the API, pretty much. What bulk stuff
would be used?
Grahame
I don't think so as the validate query should be really fast as many of
these calls may need to occur in a short amount of time (for example when
validating all codes within a CDA document)
would it make much difference?
That sounds like a good idea to me, then if more details are needed they can
be explicitly fetched.
This would be of value to the IL as we will likely need to validate a number
of codes at once to validate all terminology in a single CDA document and
this may have an efficiency benefit. However, this isn't strictly required
as the same could be accomplished with multiple calls to number 1, we would
just gain some efficiency.
I'll work on it
Grahame
I don’t believe that the addition of display or concept names should have a negative effect on query responsiveness.
Jack
···
On Tuesday, October 21, 2014 3:08:48 AM UTC-4, grahame wrote:
I don’t think so as the validate query should be really fast as many of
these calls may need to occur in a short amount of time (for example when
validating all codes within a CDA document)
would it make much difference?
That sounds like a good idea to me, then if more details are needed they can
be explicitly fetched.
This would be of value to the IL as we will likely need to validate a number
of codes at once to validate all terminology in a single CDA document and
this may have an efficiency benefit. However, this isn’t strictly required
as the same could be accomplished with multiple calls to number 1, we would
just gain some efficiency.
I’ll work on it
Grahame