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
 
(40 intermediate revisions by 3 users not shown)
Line 3: Line 3:
  
 
=Scope=
 
=Scope=
The scope of this effort is only for Lab Orders/Results/Reports at this time.
+
Resources under development by OO:
=Documents=
+
*[http://hl7-fhir.github.io/*BodySite.html BodySite]
FHIR Models: [http://www.hl7.org/implement/standards/fhir/labreport.htm LabReport]
+
*[http://hl7-fhir.github.io/*DataElement.html DataElement]
Review Notes on Lab FHIR Models: [[LabReportDiscussion]]
+
*[http://hl7-fhir.github.io/*Device.html Device]
 +
*[http://hl7-fhir.github.io/*DiagnosticOrder.html  DiagnosticOrder ]
 +
*[http://hl7-fhir.github.io/*DiagnosticReport.html *iagnosticReport]
 +
*[http://hl7-fhir.github.io/*NutitionOrder.html NutitionOrder]
 +
*[http://hl7-fhir.github.io/*Observation.html Observation]
 +
*[http://hl7-fhir.github.io/*Order.html Order]
 +
*[http://hl7-fhir.github.io/*OrderResponse.html OrderResponse]
 +
*[http://hl7-fhir.github.io/*Specimen.html Specimen]
 +
*[http://hl7-fhir.github.io/*Substance.html Substance]
 +
*[http://hl7-fhir.github.io/*Supply.html Supply]
 +
 
 +
 
 +
=Next Steps=
 +
 
 +
*
 +
== Resolve Ballot comments ==
 +
 
 +
*pending see [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677 GFORGE]
 +
 
 +
== DSTU2 QA ==
 +
 
 +
1) divide up the work -  here is list of OO's resouces pick what you want and I will take whatever is left over:
 +
 
 +
  1.Order - Elvino
 +
 
 +
  2.OrderResponse - Elvino
 +
 
 +
  3.DiagnosticOrder - Elvino
 +
 
 +
  4.DiagnosticReport
 +
 
 +
  5.NutritionOrder - Eric
 +
 
 +
  6.Observation
 +
 
 +
  7.Specimen
 +
 
 +
  8.Supply
 +
 
 +
  9.Device
 +
 
 +
  10.Substance
 +
 
 +
  11.BodySite  - Eric
 +
 
 +
  12. DataElement - Lloyd
 +
 
 +
 
 +
2) Review QA process here and see Lloyd's comments
 +
 
 +
"The specific quality assurance rules can be found here: http://wiki.hl7.org/index.php?title=DSTU_2_QA_guidelines
 +
 
 +
 
 +
Of these, I'd like the clinical folks to help out with the following:
 +
 
 +
 
 +
Introduction: all three rules.  Copy the existing introduction down to the end of the "Boundaries and Relationships" section for the resource into MS-Word, turn on track changes and edit it to meet the QA rules. 
 +
 
 +
Examples: Look at the HTML view of the examples that already exist and see what they cover in terms of the contexts and data elements.  If they need edits to make them clinically correct or if they can be edited to provide more coverage of contexts or data elements, then copy them to MS word and edit with track changes.  Then define additional examples to cover additional contexts and ensure that all of the data elements are exercised at least once.
 +
 
 +
Value sets: Check for completeness.  If you know terminology well enough to propose/design an external value set, that'd be good too.
 +
 
 +
Definitions: If you want to beef up a definition, feel free
 +
 
 +
Search criteria: Do the search criteria cover the 80% - any that seem like edge cases?  Any common ones missing?
 +
 
 +
If you have questions/concerns, ask :>'
 +
 
 +
 
 +
3) Any proposed changes outside of typos and broken links which can be fixed without review should be put in gFORGE as a comment for group block vote prior to review prior to committing.
 +
 
 +
- In order to sort QA comments thecomment summary should start with "QA-[Resource]"
 +
 
 +
4) Send a list of QA changes out on OO list for each resource when complete to get group consensus and chance for review. 
 +
 
 +
5) Any individual items can be brought up on weekly call, but in interest of time try to get a resolution off line so can do a block vote.
  
=Discussion=
+
6) One last thing -Don't make a comment if no changes are needed
Patrick reviewed the definitions for the FHIR Resource for LabReport.  My comments are as follows:
 
  
#General
+
=Documents=
##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
+
*Review Notes (Jan 2013) on Lab FHIR Models: [[LabReportDiscussion]]
### GG: this is not a naming question, but scoping/analysis problem. We need to discuss use cases
 
### PL: Agree completely!
 
### GG: Actually, I think the scope is correct in this regard. This resource allows you to 'report'... but you can also use it just to send atomic results.
 
#Business
 
## LabReport.Issued: don't understand the definition
 
### GG: revision date time - need to fix the name/definition
 
## 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
 
### 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?
 
### GG: open question - but why are you asking? this resource is not a promise, nor a fulfillment - that would be something else that might point to this.
 
#Technical
 
## 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
 
### GG: that's what "meaning" is for
 
## 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
 
### GG: what's the use case? Creatinine Clearance I suppose? but this does complicate matters - is it worth it? I thought it was outside the 80/20
 
## Result.codedDx (or some such).  Need interpretation per result (esp. for micro)
 
### GG: agree - need to add interpretation - or we could change comments to interpretation and make it coded - but would you use both?
 
## 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
 
### GG: well, how is it different, and what difference does it make in practice?
 
## 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. Note that withdrawn = changed/updated, but with formal notification that this change means, withdrawn. This allows the receiving system to actually remove (in whatever way is appropriate) the contents
 
## 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 a resource. Which codes did you have in mind?
 

Latest revision as of 19:09, 10 February 2015

Introduction

This is the project page for the development of FHIR resources in the OO domain. Project #952

Scope

Resources under development by OO:


Next Steps

Resolve Ballot comments

DSTU2 QA

1) divide up the work - here is list of OO's resouces pick what you want and I will take whatever is left over:

 1.Order - Elvino
 2.OrderResponse - Elvino
 3.DiagnosticOrder - Elvino
 4.DiagnosticReport
 5.NutritionOrder - Eric
 6.Observation
 7.Specimen
 8.Supply
 9.Device 
 10.Substance
 11.BodySite  - Eric
 12. DataElement - Lloyd


2) Review QA process here and see Lloyd's comments

"The specific quality assurance rules can be found here: http://wiki.hl7.org/index.php?title=DSTU_2_QA_guidelines


Of these, I'd like the clinical folks to help out with the following:


Introduction: all three rules. Copy the existing introduction down to the end of the "Boundaries and Relationships" section for the resource into MS-Word, turn on track changes and edit it to meet the QA rules.

Examples: Look at the HTML view of the examples that already exist and see what they cover in terms of the contexts and data elements. If they need edits to make them clinically correct or if they can be edited to provide more coverage of contexts or data elements, then copy them to MS word and edit with track changes. Then define additional examples to cover additional contexts and ensure that all of the data elements are exercised at least once.

Value sets: Check for completeness. If you know terminology well enough to propose/design an external value set, that'd be good too.

Definitions: If you want to beef up a definition, feel free

Search criteria: Do the search criteria cover the 80% - any that seem like edge cases? Any common ones missing?

If you have questions/concerns, ask :>'


3) Any proposed changes outside of typos and broken links which can be fixed without review should be put in gFORGE as a comment for group block vote prior to review prior to committing.

- In order to sort QA comments thecomment summary should start with "QA-[Resource]"

4) Send a list of QA changes out on OO list for each resource when complete to get group consensus and chance for review.

5) Any individual items can be brought up on weekly call, but in interest of time try to get a resolution off line so can do a block vote.

6) One last thing -Don't make a comment if no changes are needed

Documents