This wiki has undergone a migration to Confluence found Here

Difference between revisions of "FHIR for Orders"

From HL7Wiki
Jump to navigation Jump to search
Line 11: Line 11:
 
#General
 
#General
 
##Resource Naming: Suggest LabReport isn't the correct name.  Not all regions 'bundle' their results in the form of a report (which, to OO, is a 'clinical document').  Need to discuss the architecture used: namely, report is made up of groups, made up of results
 
##Resource Naming: Suggest LabReport isn't the correct name.  Not all regions 'bundle' their results in the form of a report (which, to OO, is a 'clinical document').  Need to discuss the architecture used: namely, report is made up of groups, made up of results
 +
### GG: this is not a naming question, but scoping/analysis problem. We need to discuss use cases
 
#Business
 
#Business
 
## LabReport.Issued: don't understand the definition
 
## LabReport.Issued: don't understand the definition
 +
### GG: revision date time
 
## LabReport.Specimen:  Why specimen at the report level,. esp considering at the report level, multiple specimens are supported
 
## LabReport.Specimen:  Why specimen at the report level,. esp considering at the report level, multiple specimens are supported
 +
### GG: because it seems silly to repeat the same specimen for multiple groups - and this is a common situation
 
## ResultGroup: what's the requirement
 
## ResultGroup: what's the requirement
 +
### GG: this allows a single structure to handle all the reports we could find - sections/categories in common reports, immunology (a series of observations per antibody), micro (groups for organisms), Sections in synoptic reports (CAP definitions)
 
## Does Promise as a resource meet the 80/20 rule or is a promise simply a special kind of result?
 
## Does Promise as a resource meet the 80/20 rule or is a promise simply a special kind of result?
 +
### GG: open question
 
#Technical
 
#Technical
 
## RequestDetail.receiverOrderId:  No requirement
 
## RequestDetail.receiverOrderId:  No requirement
 +
### GG: I got lazy. I should add something
 
## ReferenceRange: missing another element.  Can say Normal range and give the numbers.  but can't say normal range for a male over 50 yo
 
## ReferenceRange: missing another element.  Can say Normal range and give the numbers.  but can't say normal range for a male over 50 yo
 +
### GG: that's what "meaning" is for
 
## Result.name: ResultGroup.name: Element names are wonky (don't like 'name') where used in this spec.
 
## Result.name: ResultGroup.name: Element names are wonky (don't like 'name') where used in this spec.
 +
### GG: so we talk about renaming. I'd use "code" now.
 
## An individual result should be able to reference a specimen, in my opinion
 
## An individual result should be able to reference a specimen, in my opinion
 +
### GG: what's the use case? Creatinine Clearance I suppose? but this does complicate matters - is it worth it?
 
## Result.codedDx (or some such).  Need interpretation per result (esp. for micro)
 
## Result.codedDx (or some such).  Need interpretation per result (esp. for micro)
 +
### GG: agree - need to add interpretation
 
## LabReport.status: No use case for registered
 
## LabReport.status: No use case for registered
 +
### GG: yes there is - common to be required to let clinicians know that a report is coming.
 
## LabReport.status: interim, different than preliminary
 
## LabReport.status: interim, different than preliminary
 +
### GG: well, how is it different, and what difference does it make in practice?
 
## LabReport.status: No use case for withdrawn
 
## LabReport.status: No use case for withdrawn
 +
### GG: ? how can you not have a use case - what do you do when you want to withdraw a result? This is widely used in Australia
 
## LabReport.status: Does this follow 80/20 too?  Depending, we should consider adding the newer codes added for v2 for result status
 
## LabReport.status: Does this follow 80/20 too?  Depending, we should consider adding the newer codes added for v2 for result status
 +
### GG: well, some of the codes are outside the scope of this. Which codes did you have in mind?

Revision as of 18:05, 12 September 2012

Introduction

This page is for comments (we need a PSS to do more) as OO reviews the currently designed FHIR artifacts for Laboratory.

Scope

The scope of this effort is only for Lab Orders/Results/Reports at this time.

Documents

FHIR Models: LabReport

Discussion

Patrick reviewed the definitions for the FHIR Resource for LabReport. My comments are as follows:

  1. General
    1. Resource Naming: Suggest LabReport isn't the correct name. Not all regions 'bundle' their results in the form of a report (which, to OO, is a 'clinical document'). Need to discuss the architecture used: namely, report is made up of groups, made up of results
      1. GG: this is not a naming question, but scoping/analysis problem. We need to discuss use cases
  2. Business
    1. LabReport.Issued: don't understand the definition
      1. GG: revision date time
    2. LabReport.Specimen: Why specimen at the report level,. esp considering at the report level, multiple specimens are supported
      1. GG: because it seems silly to repeat the same specimen for multiple groups - and this is a common situation
    3. ResultGroup: what's the requirement
      1. GG: this allows a single structure to handle all the reports we could find - sections/categories in common reports, immunology (a series of observations per antibody), micro (groups for organisms), Sections in synoptic reports (CAP definitions)
    4. Does Promise as a resource meet the 80/20 rule or is a promise simply a special kind of result?
      1. GG: open question
  3. Technical
    1. RequestDetail.receiverOrderId: No requirement
      1. GG: I got lazy. I should add something
    2. ReferenceRange: missing another element. Can say Normal range and give the numbers. but can't say normal range for a male over 50 yo
      1. GG: that's what "meaning" is for
    3. Result.name: ResultGroup.name: Element names are wonky (don't like 'name') where used in this spec.
      1. GG: so we talk about renaming. I'd use "code" now.
    4. An individual result should be able to reference a specimen, in my opinion
      1. GG: what's the use case? Creatinine Clearance I suppose? but this does complicate matters - is it worth it?
    5. Result.codedDx (or some such). Need interpretation per result (esp. for micro)
      1. GG: agree - need to add interpretation
    6. LabReport.status: No use case for registered
      1. GG: yes there is - common to be required to let clinicians know that a report is coming.
    7. LabReport.status: interim, different than preliminary
      1. GG: well, how is it different, and what difference does it make in practice?
    8. LabReport.status: No use case for withdrawn
      1. GG: ? how can you not have a use case - what do you do when you want to withdraw a result? This is widely used in Australia
    9. LabReport.status: Does this follow 80/20 too? Depending, we should consider adding the newer codes added for v2 for result status
      1. GG: well, some of the codes are outside the scope of this. Which codes did you have in mind?