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

Difference between revisions of "Catalog FHIR Profile Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Profile Proposal}}")
 
(migrate to Confluence)
 
(19 intermediate revisions by one other user not shown)
Line 1: Line 1:
  
 
<div class="messagebox cleanup metadata">
 
<div class="messagebox cleanup metadata">
−
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
+
Current version: https://confluence.hl7.org/display/FHIR/Catalog+FHIR+Profile+Proposal<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
Line 14: Line 14:
  
  
−
=PutProposedProfileNameHere=
+
=Catalog (Draft)=
  
 
<!-- Profile names should meet the following characteristics:
 
<!-- Profile names should meet the following characteristics:
Line 31: Line 31:
 
==Profile balloting plans==
 
==Profile balloting plans==
  
 +
*For Comment ballot in January 2018
 +
*STU ballot May 2018
  
 
==Profile Details==
 
==Profile Details==
Line 37: Line 39:
  
 
<!--Put a link to the resource/datatype (or group of resources) that will be profiled here.-->
 
<!--Put a link to the resource/datatype (or group of resources) that will be profiled here.-->
−
* [[ParentResourceAddress|ResourceName]]
+
*[http://hl7.org/fhir/composition.html Composition]
  
 
====Constraints to be Applied====
 
====Constraints to be Applied====
  
 
<!--Describe how the current resource will be constrained.-->
 
<!--Describe how the current resource will be constrained.-->
−
* Constraint 1
+
*Constraint subject to 0..0; Catalog is non patient specific
−
* Constraint 2
+
*Define value sets for documentTypeCode and Composition.class (or constrain out Composition.class)
  
 
====Extensions to be Applied====
 
====Extensions to be Applied====
  
 
<!--Describe how the current resource will be extended.-->
 
<!--Describe how the current resource will be extended.-->
−
* Extension 1
+
*Add an extension for PublishedDate, unless SD wants to consider that for core
−
* Extension 2
+
*Add an extension for ValidityPeriod, unless SD wants to consider that for core
 +
*Provide for inclusion of subCompositions (subCatalogs) as an extension
 +
*Determine how to address lifecycle stage (Draft, Published, etc)
  
 
===Example Scenarios===
 
===Example Scenarios===
  
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this Profile.  They should demonstrate the full scope of the Profile and allow exercising of the Profiles capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this Profile.  They should demonstrate the full scope of the Profile and allow exercising of the Profiles capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 +
 +
*Medication Formulary within an institution
 +
*Orderable Devices Catalog
 +
*Lab Electronic Directory of Service
 +
*Catalog of Order Sets
 +
*Human Services Directories
 +
*Catalog of Approved Protocols in an Institution
  
 
===Scope of coverage===
 
===Scope of coverage===
Line 67: Line 78:
 
As a rule, Profiles should encompass all of these aspects.
 
As a rule, Profiles should encompass all of these aspects.
 
-->
 
-->
 +
 +
Order Service Catalogs vary in the type of entries they contain. For instance, a product catalog such as a medication catalog may list products that are available for selection within a single organization or across a number of organizations;  an orderable catalog typically holds collections of orderable items available to an organization or facility, the definition of orderables used to render and constrain order entry forms, and libraries of order set or plan of care definitions for any number of patient populations.  Other examples include Electronic Delivery of Service (eDOS) compliant catalogs that enumerate the orderable tests for laboratories or medication product catalogs.
 +
 +
Service catalogs may offer a set of services that can be ordered such as laboratory services and may also contain entries in the catalog for items that are not necessarily orderable but rather which serve a supporting role when ordering a specific service.
 +
 +
Catalogs of knowledge artifacts, another type of order service catalog, enable organizations to ensure that high quality standards are maintained over time. Order sets and plans of care evolve as best practices and evidence change, but without standardized Catalog APIs, it is often not easy or even possible to exchange catalog resources between organizations. For instance, an organization may decide to contract with a CDS Knowledge Provider to obtain evidence-based order sets to help them standardize care. The organization may wish to customize these order sets (e.g., modifying the names of orderable items to reflect the local vocabulary used at a given facility or changing the data models of categories of orderables such as medication orderables), and, with great effort, import these customized order sets into their EMR. Given the lack of standard interfaces to support the import of such order sets, updating local content as evidence-based practices evolve is unnecessarily convoluted and expensive. 
 +
 +
An Order Catalog consists of Catalog Entries — items such as medication products, laboratory tests, procedures, or knowledge artifacts such as order sets—which support the ordering process as well as groups of such entries. Fundamentally, an Order Catalog consists of the collection of Catalog Entries that make up the catalog and any associated metadata that describes the overall collection. 
 +
The content of a catalog consist of entries of three types: catalog entry groups which supports the grouping of entries in a catalog, catalog entries representing an individual entry in the catalog, and references to other entries in the catalog to support easier organization of catalog content.
  
 
===Realm===
 
===Realm===
−
Please describe the realm to which this profile applies, or indicate that it is realm neutral.
+
 
 +
Realm Neutral
  
 
==Ownership==
 
==Ownership==
Line 75: Line 96:
  
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the Profiles. -->
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the Profiles. -->
−
[[YourCommitteeName]]
+
[[Orders_%26_Observations_WG | Orders and Observations]]
  
 
===Contributing or Reviewing Work Groups===
 
===Contributing or Reviewing Work Groups===
  
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the Profile (optional) -->
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the Profile (optional) -->
−
* Work Group Name
+
*Reviewing Work Group:
−
* or link
+
**Structured Documents (Approved Sept 11, 2017)
−
* or "None"
+
*Contributing WorkGroups:
 +
**Pharmacy
 +
**Clinical Decision Support
 +
**Imaging Integration
 +
**Service Oriented Architecture
  
 
===Expected implementations===
 
===Expected implementations===
  
 
<!--Key Profiles are justified by CCDA, for Profiles not deemed "key", what interest is there by implementers in using this particular Profile. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
<!--Key Profiles are justified by CCDA, for Profiles not deemed "key", what interest is there by implementers in using this particular Profile. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 +
 +
*IHE will require a catalog of medications for profiling and guidance
 +
*LIVD project (LOINC - IVD Test Code) intends to use this profile
 +
*FHIR based eDOS implementations
  
 
===gForge Users===
 
===gForge Users===
  
 
<!-- Identify the userids who will require commit access to gForge to maintain the Profile.  (Ensure all users have registered for gForge.) -->
 
<!-- Identify the userids who will require commit access to gForge to maintain the Profile.  (Ensure all users have registered for gForge.) -->
−
 
+
Claude Nanjo, Jose Teixera
  
 
===FHIR Profile Development Project Insight ID===
 
===FHIR Profile Development Project Insight ID===
  
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 +
 +
1010
  
 
==Plans==
 
==Plans==
Line 101: Line 132:
  
 
<!-- Indicate the target date for having the Profile complete from a committee perspective and ready for vetting and voting -->
 
<!-- Indicate the target date for having the Profile complete from a committee perspective and ready for vetting and voting -->
−
*TargetDateForInternalReview
+
*Planning for Design Review in time for January 2018 Connectathon
  
 
===Balloting Requirements===
 
===Balloting Requirements===
Line 108: Line 139:
  
 
Choose one:
 
Choose one:
 +
 
*Ballot with next FHIR DSTU or Normative Edition
 
*Ballot with next FHIR DSTU or Normative Edition
−
*or Ballot independently as DSTU
+
 
−
*or Realm specific ballot
 
−
*or No Ballot
 
  
 
<!-- Indicate the desired ballot date.-->
 
<!-- Indicate the desired ballot date.-->
 
Desired Ballot Date
 
Desired Ballot Date
−
*PutDesiredBallotDateHere
+
 
 +
*As scheduled by overall FHIR ballot

Latest revision as of 16:05, 31 October 2019

Current version: https://confluence.hl7.org/display/FHIR/Catalog+FHIR+Profile+Proposal
OpenHotTopic.GIF

This page documents a Pending FHIR Resource Proposal



Catalog (Draft)

Profile balloting plans

  • For Comment ballot in January 2018
  • STU ballot May 2018

Profile Details

Profiled Resource(s)

Constraints to be Applied

  • Constraint subject to 0..0; Catalog is non patient specific
  • Define value sets for documentTypeCode and Composition.class (or constrain out Composition.class)

Extensions to be Applied

  • Add an extension for PublishedDate, unless SD wants to consider that for core
  • Add an extension for ValidityPeriod, unless SD wants to consider that for core
  • Provide for inclusion of subCompositions (subCatalogs) as an extension
  • Determine how to address lifecycle stage (Draft, Published, etc)

Example Scenarios

  • Medication Formulary within an institution
  • Orderable Devices Catalog
  • Lab Electronic Directory of Service
  • Catalog of Order Sets
  • Human Services Directories
  • Catalog of Approved Protocols in an Institution

Scope of coverage

Order Service Catalogs vary in the type of entries they contain. For instance, a product catalog such as a medication catalog may list products that are available for selection within a single organization or across a number of organizations; an orderable catalog typically holds collections of orderable items available to an organization or facility, the definition of orderables used to render and constrain order entry forms, and libraries of order set or plan of care definitions for any number of patient populations. Other examples include Electronic Delivery of Service (eDOS) compliant catalogs that enumerate the orderable tests for laboratories or medication product catalogs.

Service catalogs may offer a set of services that can be ordered such as laboratory services and may also contain entries in the catalog for items that are not necessarily orderable but rather which serve a supporting role when ordering a specific service.

Catalogs of knowledge artifacts, another type of order service catalog, enable organizations to ensure that high quality standards are maintained over time. Order sets and plans of care evolve as best practices and evidence change, but without standardized Catalog APIs, it is often not easy or even possible to exchange catalog resources between organizations. For instance, an organization may decide to contract with a CDS Knowledge Provider to obtain evidence-based order sets to help them standardize care. The organization may wish to customize these order sets (e.g., modifying the names of orderable items to reflect the local vocabulary used at a given facility or changing the data models of categories of orderables such as medication orderables), and, with great effort, import these customized order sets into their EMR. Given the lack of standard interfaces to support the import of such order sets, updating local content as evidence-based practices evolve is unnecessarily convoluted and expensive. 

An Order Catalog consists of Catalog Entries — items such as medication products, laboratory tests, procedures, or knowledge artifacts such as order sets—which support the ordering process as well as groups of such entries. Fundamentally, an Order Catalog consists of the collection of Catalog Entries that make up the catalog and any associated metadata that describes the overall collection.  The content of a catalog consist of entries of three types: catalog entry groups which supports the grouping of entries in a catalog, catalog entries representing an individual entry in the catalog, and references to other entries in the catalog to support easier organization of catalog content.

Realm

Realm Neutral

Ownership

Owning committee name

Orders and Observations

Contributing or Reviewing Work Groups

  • Reviewing Work Group:
    • Structured Documents (Approved Sept 11, 2017)
  • Contributing WorkGroups:
    • Pharmacy
    • Clinical Decision Support
    • Imaging Integration
    • Service Oriented Architecture

Expected implementations

  • IHE will require a catalog of medications for profiling and guidance
  • LIVD project (LOINC - IVD Test Code) intends to use this profile
  • FHIR based eDOS implementations

gForge Users

Claude Nanjo, Jose Teixera

FHIR Profile Development Project Insight ID

1010

Plans

Timelines

  • Planning for Design Review in time for January 2018 Connectathon

Balloting Requirements

Choose one:

  • Ballot with next FHIR DSTU or Normative Edition


Desired Ballot Date

  • As scheduled by overall FHIR ballot
Retrieved from "https://wiki.hl7.org/w/index.php?title=Catalog_FHIR_Profile_Proposal&oldid=166895"