This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Catalog"

From HL7Wiki
Jump to navigation Jump to search
 
(9 intermediate revisions by 2 users not shown)
Line 14: Line 14:
 
==Justification==
 
==Justification==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
−
Resources and Resource profiles needed support catalogs of various types (lab compendia, medication formularies, human services directories, etc) are in an early draft stage.  These include a Catalog profile on Composition, a catalog entry EntryDefinition resource, an ObservationDefinition resource, a SpecimenDefinition resource, and potentially a profile on ActivityDefinition. This connectathon track is intended to test the design approach and confirm the resource set meets the needs of the use case.
+
Resources and Resource profiles needed to support catalogs of various types (lab compendia, medication formularies, human services directories, etc) are in an early draft stage.  These include a Catalog profile on Composition, a catalog entry EntryDefinition resource, an ObservationDefinition resource, a SpecimenDefinition resource, and potentially a profile on ActivityDefinition. This connectathon track is intended to test the design approach and confirm the resource set meets the needs of the use case. The track is based on the current R4 ballot (http://hl7.org/fhir/2018Jan/index.html)
  
 
This will inform the development of the catalog resources, which will be balloted as draft for the January 2018 ballot, and a goal of FMM 1 for the FHIR Release 4 ballot in May 2018.
 
This will inform the development of the catalog resources, which will be balloted as draft for the January 2018 ballot, and a goal of FMM 1 for the FHIR Release 4 ballot in May 2018.
Line 50: Line 50:
 
**ObservationDefinition
 
**ObservationDefinition
  
−
A FHIR server will be available for testing with sample data at http://jade.phast.fr/DEV_VISIONNEUSE/api/FHIR
+
A FHIR server will be available for testing with sample data at http://jade.phast.fr/catalogs/api/fhir
 +
 
 +
PHAST use case
 +
* The laboratory managing and hosting its own tests/panels catalog. The application managing this catalog is the catalog server.
  
 
===Catalog Consumer===
 
===Catalog Consumer===
 
This connectathon track focuses on the retrieval of a EntryDefinition and its set of related resources, to support an order. In this case, a catalog consumer could be a Lab Information System (LIS), a Computerized Order Entry System, or an EHR.
 
This connectathon track focuses on the retrieval of a EntryDefinition and its set of related resources, to support an order. In this case, a catalog consumer could be a Lab Information System (LIS), a Computerized Order Entry System, or an EHR.
 +
 +
PHAST use case
 +
* A physician willing to place test orders to a clinical laboratory for his patients, and needing to check the associated pre-analytical conditions as well as what results will be reported back, and how.  The physician’s EHR system is the client application.
  
 
==Scenarios==
 
==Scenarios==
Line 59: Line 65:
 
This track demonstrates basic catalog interactions to support the ordering process, with a focus on lab tests. Future connectathons will explore other catalog types and more complex catalog management and maintenance tasks.
 
This track demonstrates basic catalog interactions to support the ordering process, with a focus on lab tests. Future connectathons will explore other catalog types and more complex catalog management and maintenance tasks.
  
−
<ToDo - These need to be fleshed out over the next week or so. Also need to confer with Motive around Knowledge Artifact scenarios>
+
===Initial Search===
 +
 
 +
====Search by name of specialty====
 +
The physician enters some word(s) which are part of the name of a laboratory sub-specialty, such as “chemistry”, “virology”, “toxicology”, “bacteriology”, …
 +
His EHR-S launches the search with search parameters corresponding to:
 +
*EntryDefinition.classification.display = <the words keyed in>
 +
*EntryDefinition.purpose = ”orderable”
 +
*EntryDefinition.type = “service”
 +
 
 +
====Search by name of orderable service====
 +
The physician enters some word(s) which are part of the name of an orderable service, such as “CBC”, “electrolyte”, “toxoplasma”, “sodium” …
 +
His EHR-S launches the search with search parameters corresponding to:
 +
*EntryDefinition.purpose = ”orderable”
 +
*EntryDefinition.type = “service”
 +
*EntryDefinition.referencedItem→ActivityDefinition.name= <words keyed in>
 +
 
 +
====Response====
 +
 
 +
In both cases, the server responds with a list of EntryDefinition resources satisfying the criterion. Each item of the list presents a few summary elements of both EntryDefinition and the referenced item ActivityDefinition.
 +
 
 +
The physician’s EMR system displays the list on screen, with the elements, which make sense to this application. In particular:
 +
*ActivityDefinition.identifier = the LOINC code of the orderable service
 +
*ActivityDefinition.name = name of the orderable service
 +
*EntryDefinition.classification.display = the name of the sub-specialty
 +
*EntryDefinition.identifier
  
−
===Search Compendium for Tests===
+
===Obtain detail for one orderable service===
−
*Request list of catalog entries matching specific criteria <ToDo: need to expand on the criteria for searching>
 
−
*Query the specific catalog entry of a service, to support an order for this service. The response will carry:
 
−
**input observations required by the service
 
−
**observations produced as output of the service,
 
−
**specimens required to perform the service.
 
−
*Bonus: creating an Order for a specific Patient based on the returned catalog items.
 
  
−
<!-- Provide a description of each task -->
+
The physician selects one item of the list.
 +
His EHR-S launches the GET on the identified EntryDefinition
  
−
===Add Entry to Compendium===
+
The server responds with:
−
The laboratory catalog vendor needs to create an entry in their catalog for a specific test (for instance for Serum Potassium):
+
*the detail of the EntryDefinition
−
*Create dependent ObservationDefinitions and SpecimenDefinitions needed for this entry
+
*its referenced item ActivityDefinition
−
*Create the ActivityDefinition that represents the Orderable Lab Service
+
*its related items:
−
*Create Catalog EntryDefinition representing the Orderable Item and Dependencies
+
**SpecimenDefinition resources representing the biologic specimens to be provided when ordering this service, with the characteristics of each specimen.
−
*Associate dependent definitions with the Lab Service Activity Definition
+
**ObservationDefinition resources representing the observations to provide as input to the service: questions to be asked at order entry or at specimen collection time.
 +
**ObservationDefinition resources characterizing the results that the laboratory will produce as output of the service
 +
**The ActivityDefinition resources representing the child services that this service may trigger (e.g. as reflex panels or tests)
  
 
==TestScript(s)==
 
==TestScript(s)==

Latest revision as of 17:40, 16 January 2018



Return to Jan 2018 Proposals

Order Catalog

Submitting WG/Project/Implementer Group

  • Orders and Observations

Justification

Resources and Resource profiles needed to support catalogs of various types (lab compendia, medication formularies, human services directories, etc) are in an early draft stage. These include a Catalog profile on Composition, a catalog entry EntryDefinition resource, an ObservationDefinition resource, a SpecimenDefinition resource, and potentially a profile on ActivityDefinition. This connectathon track is intended to test the design approach and confirm the resource set meets the needs of the use case. The track is based on the current R4 ballot (http://hl7.org/fhir/2018Jan/index.html)

This will inform the development of the catalog resources, which will be balloted as draft for the January 2018 ballot, and a goal of FMM 1 for the FHIR Release 4 ballot in May 2018.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Claude Nanjo
Email: cnanjo@gmail.com
Zulip: Claude Nanjo
François Macary
Email: francois.macary@phast.fr
Zulip: François Macary

Expected participants

The following organizations have indicated an interest in participating in this track:

  • Phast - Phast will participate with a FHIR server supporting a Lab Compendium
  • Motive MI -Knowledge artifact catalog
  • Cognitive Medical Systems - acting as a consumer for Knowledge artifacts, and potentially labs
  • Your organization here!

Roles

Please include information here regarding how much advance preparation will be required if creating a client and/or server.

Catalog Server

A FHIR Server should support the following resources for this track:

  • Catalog Profile of Composition
  • EntryDefinition
  • Content resources appropriate to the type of catalog. For Lab:
    • ActivityDefinition
    • SpecimenDefinition
    • ObservationDefinition

A FHIR server will be available for testing with sample data at http://jade.phast.fr/catalogs/api/fhir

PHAST use case

  • The laboratory managing and hosting its own tests/panels catalog. The application managing this catalog is the catalog server.

Catalog Consumer

This connectathon track focuses on the retrieval of a EntryDefinition and its set of related resources, to support an order. In this case, a catalog consumer could be a Lab Information System (LIS), a Computerized Order Entry System, or an EHR.

PHAST use case

  • A physician willing to place test orders to a clinical laboratory for his patients, and needing to check the associated pre-analytical conditions as well as what results will be reported back, and how. The physician’s EHR system is the client application.

Scenarios

This track demonstrates basic catalog interactions to support the ordering process, with a focus on lab tests. Future connectathons will explore other catalog types and more complex catalog management and maintenance tasks.

Initial Search

Search by name of specialty

The physician enters some word(s) which are part of the name of a laboratory sub-specialty, such as “chemistry”, “virology”, “toxicology”, “bacteriology”, … His EHR-S launches the search with search parameters corresponding to:

  • EntryDefinition.classification.display = <the words keyed in>
  • EntryDefinition.purpose = ”orderable”
  • EntryDefinition.type = “service”

Search by name of orderable service

The physician enters some word(s) which are part of the name of an orderable service, such as “CBC”, “electrolyte”, “toxoplasma”, “sodium” … His EHR-S launches the search with search parameters corresponding to:

  • EntryDefinition.purpose = ”orderable”
  • EntryDefinition.type = “service”
  • EntryDefinition.referencedItem→ActivityDefinition.name= <words keyed in>

Response

In both cases, the server responds with a list of EntryDefinition resources satisfying the criterion. Each item of the list presents a few summary elements of both EntryDefinition and the referenced item ActivityDefinition.

The physician’s EMR system displays the list on screen, with the elements, which make sense to this application. In particular:

  • ActivityDefinition.identifier = the LOINC code of the orderable service
  • ActivityDefinition.name = name of the orderable service
  • EntryDefinition.classification.display = the name of the sub-specialty
  • EntryDefinition.identifier

Obtain detail for one orderable service

The physician selects one item of the list. His EHR-S launches the GET on the identified EntryDefinition

The server responds with:

  • the detail of the EntryDefinition
  • its referenced item ActivityDefinition
  • its related items:
    • SpecimenDefinition resources representing the biologic specimens to be provided when ordering this service, with the characteristics of each specimen.
    • ObservationDefinition resources representing the observations to provide as input to the service: questions to be asked at order entry or at specimen collection time.
    • ObservationDefinition resources characterizing the results that the laboratory will produce as output of the service
    • The ActivityDefinition resources representing the child services that this service may trigger (e.g. as reflex panels or tests)

TestScript(s)

Security and Privacy Considerations

Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_Catalog&oldid=151214"