search

hl7-be / lab

Creative Commons Zero v1.0 Universal
6 stars 9 forks source link

How to encode comments #23

Closed tomto66 closed 2 years ago

tomto66 commented 3 years ago

We need to specify how to deal with different kinds of comments. Here an inventory and suggestion of process:

a. Comment on a result of analysis - may be done .note to the result? But there are different cases possible: a.i. result field itself maybe comment or text (e.g. "Positive" or "No longer performed by lab; replaced by analyses XXX" a.ii. Comment in commentfield may be combined with number (or comment0 in result field)

b. Comment regd. reference values (e.g. age-specifics) – in .text to the reference values? c. We often created dummy test codes to contain comments. E.g. serum aspect. Is this allowed? There are no LOINC codes for these dummies - will we allow every lab to use their own. Can we use this system? If not, how do we encode such comment?

d. Comments regarding the laboratory (not the results). E.g. status of accreditation. We currently use dummy tests for that. Acceptable? If not, then how?

e. Comments regarding tests performed by 3rd parties. We currently do that by means of flags (codes) next to results, and use a dummy test to explain the legend. Allowed? If not then how?

f. Comments regarding administrative issue, e.g. missing information like gender, DOB. Today we use dummy test codes. Allowed? If not, then how?

g. There is also a .conclusionCode - to use instead of dummy analyses? Or a combination? Dummy analysis have the advantage they can be linked to a sample (useful e.g. for serum aspect) - .conclusionCodes cannot do this.

Do we want/need to agree on standards for the above? Or allwo every lab to do their own way?

costateixeira commented 3 years ago

I think we could add some narrative, but it would be better to add such use cases to our specification, and provide the example FHIR resource instances. If we have some narrative text, we can explain the mechanism (this may be subject to interpretation) If we list the use cases, we can make it much more concrete by examples If we actually provide the examples, implementers will have more clarity.

bdc-ehealth commented 2 years ago

@tomto66 Can you provide an example for each case (testing dir in project) and add a reference here?

tomto66 commented 2 years ago

Yes we will provide examples!

On Wed, Nov 10, 2021 at 12:40 PM Bart Decuypere (eHealth) < @.***> wrote:

@tomto66 https://github.com/tomto66 Can you provide an example for each case (testing dir in project) and add a reference here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hl7-be/hl7-be-fhir-laboratory-report/issues/23#issuecomment-965049476, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWKYJTIWPKS7LOFFYPPU5DULJK4LANCNFSM5HEN3BNQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

bdc-ehealth commented 2 years ago

comment by Alexis Van Zeveren:

• For comments, the proper FHIR elements must be used (eg. notes), not "dummy results", either the "narrative". Tom/Macsys will try to implement this in examples. This is issue #23 in Github. It seems this decision is not yet clearly documented in the comments.