Difference between revisions of "DeviceDefinition FHIR Resource Proposal"
(migrate to Confluence) |
Riksmithies (talk | contribs) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 30: | Line 30: | ||
Orders & Observations | Orders & Observations | ||
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. --> | <!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. --> | ||
| − | |||
==Committee Approval Date:== | ==Committee Approval Date:== | ||
| Line 50: | Line 49: | ||
==Scope of coverage== | ==Scope of coverage== | ||
| − | + | This is a specialized resource that defines the characteristics and capabilities of a device. Devices include durable (reusable) medical equipment, implantable devices, as well as disposable equipment used for diagnostic, treatment and research for healthcare and public health, as well as devices such as an x-ray machine, lab analyzer, cellphone, computer, software/application, etc. A device may also be a simpler entity such as a syringe or applicator, provided with a medicinal product. | |
| − | The DeviceDefinition | + | The DeviceDefinition resource is used to describe the common characteristics and capabilities of a device of a certain type or kind, e.g., a certain model or class of a device such as a x-ray model or personal wearable device model, whereas a Device resource documents an actual instance of a device such as the actual x-ray machine that is installed or the personal wearable device being worn |
| − | + | The DeviceDefinition is typically used in catalogs, publications, or other use cases where the reference to a device is generically to a type of device, not a specific instance of a device. For example, a catalog of orderable devices, or the mapping of device specific test codes and result values to industry standards. | |
| − | |||
| − | |||
<!-- Define the full scope of coverage for the resource. The scope must be clearly delineated such that it does not overlap with any other existing or expected resource. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | <!-- Define the full scope of coverage for the resource. The scope must be clearly delineated such that it does not overlap with any other existing or expected resource. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | ||
| Line 75: | Line 72: | ||
==Resource appropriateness== | ==Resource appropriateness== | ||
| − | Separating the DeviceDefinition from Device enables | + | The DeviceDefinition resource contains the "catalog" definition of a device - whether that definition is authored by the manufacturer or a regulatory entity and allows defining valid hierarchical device configurations (devices as part of other devices). |
| + | |||
| + | Device vs DeviceDefinition: The Device resource is meant to refer to a physical instance of a device - hence having attributes like lot number, patient, location and operational status, which the DeviceDefinition resource does not have. | ||
| + | |||
| + | Separating the DeviceDefinition from Device enables clearer distinction, considering that a number of use cases primarily focus on Device, while others focus on DeviceDefinition. There will be many more Device instances than there will be DeviceDefinition instances. The DeviceDefinition would be used in catalogs and would have a different update lifecycle to the Device resource instances. | ||
<!-- Does the resource meet the following characteristics? | <!-- Does the resource meet the following characteristics? | ||
| Line 91: | Line 92: | ||
==Expected implementations== | ==Expected implementations== | ||
| − | Implementations of catalogs, e.g., LIVD as well as implementations needing to reference devices | + | Implementations of catalogs, e.g., LIVD as well as implementations needing to reference device definitions. The LIVD implementation guide addresses Lab device manufacturers to document recommended mapping of test codes and result values used on their devices using proprietary/local code systems to (inter)national vocabularies such as LOINC and SNOMED. |
| − | + | EMA plan to use this for representing the devices that are commonly supplied with medication items, within the same packaging (e.g., syringe, spoon etc). This "SPOR" project is currently implementing, with a first release in early 2020. | |
| − | |||
| − | *HL7 FHIR Device | + | |
| + | <!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->==Content sources== | ||
| + | |||
| + | *HL7 FHIR Device and DeviceMetrics | ||
*HL7 V2 EQU and DEV segments | *HL7 V2 EQU and DEV segments | ||
| + | *EMA XEVPRM implementation of regulatory medications information | ||
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | <!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | ||
| Line 105: | Line 109: | ||
==Example Scenarios== | ==Example Scenarios== | ||
| + | |||
| + | Ordering supplies using SupplyRequest would typically reference DeviceDefinitions rather than specific devices. | ||
| + | |||
| + | Ordering DME would typically reference DeviceDefinitions rather than specific devices. | ||
| + | |||
| + | Standard vocabulary mappings for devices typically define common mappings based on device models, thus DeviceDefinition rather than for each individual device. | ||
| + | |||
| + | Submission by a pharmaceutical manufacturer of the details of a packaged medicinal product for licencing by regulators (e.g. EMA, FDA, MHRA) would typically include definitions of the devices included (description, dimensions, materials, manufacturer etc). | ||
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource. They should demonstrate the full scope of the resource and allow exercising of the resources 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 resource. They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) --> | ||
| Line 113: | Line 125: | ||
*Composition | *Composition | ||
*ObservationDefinition | *ObservationDefinition | ||
| − | * | + | *PackagedMedicinalProductDefinition (contains devices as defined by DeviceDefinition) |
<!-- What are the resources do you expect will reference this resource and in what context? | <!-- What are the resources do you expect will reference this resource and in what context? | ||
Latest revision as of 20:06, 12 November 2019
This page documents a Pending FHIR Resource Proposal
Contents
- 1 DeviceDefinition
- 1.1 Owning Committee Name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Resource Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 RIM scope
- 1.7 Resource appropriateness
- 1.8 Expected implementations
- 1.9 Content sources
- 1.10 Example Scenarios
- 1.11 Resource Relationships
- 1.12 Timelines
- 1.13 gForge Users
- 1.14 When Resource Proposal Is Complete
- 1.15 FMG Notes
DeviceDefinition
Owning Committee Name
Orders & Observations
Committee Approval Date:
Please enter the date that the committee approved this Resource proposal
June 12, 2018 - http://confluence.hl7.org/display/OO/OO+Conf+Call+Minutes+-+Device+-+20180612
Contributing or Reviewing Work Groups
Healthcare Devices
- Work Group Name
- or link
- or "None"
FHIR Resource Development Project Insight ID
PI 952
Scope of coverage
This is a specialized resource that defines the characteristics and capabilities of a device. Devices include durable (reusable) medical equipment, implantable devices, as well as disposable equipment used for diagnostic, treatment and research for healthcare and public health, as well as devices such as an x-ray machine, lab analyzer, cellphone, computer, software/application, etc. A device may also be a simpler entity such as a syringe or applicator, provided with a medicinal product.
The DeviceDefinition resource is used to describe the common characteristics and capabilities of a device of a certain type or kind, e.g., a certain model or class of a device such as a x-ray model or personal wearable device model, whereas a Device resource documents an actual instance of a device such as the actual x-ray machine that is installed or the personal wearable device being worn
The DeviceDefinition is typically used in catalogs, publications, or other use cases where the reference to a device is generically to a type of device, not a specific instance of a device. For example, a catalog of orderable devices, or the mapping of device specific test codes and result values to industry standards.
RIM scope
There does not appear to be a DeviceDefinition concept in the RIM, rather only the Device instance is referenced The Common Product Model touches on elements, but not all.
Resource appropriateness
The DeviceDefinition resource contains the "catalog" definition of a device - whether that definition is authored by the manufacturer or a regulatory entity and allows defining valid hierarchical device configurations (devices as part of other devices).
Device vs DeviceDefinition: The Device resource is meant to refer to a physical instance of a device - hence having attributes like lot number, patient, location and operational status, which the DeviceDefinition resource does not have.
Separating the DeviceDefinition from Device enables clearer distinction, considering that a number of use cases primarily focus on Device, while others focus on DeviceDefinition. There will be many more Device instances than there will be DeviceDefinition instances. The DeviceDefinition would be used in catalogs and would have a different update lifecycle to the Device resource instances.
Expected implementations
Implementations of catalogs, e.g., LIVD as well as implementations needing to reference device definitions. The LIVD implementation guide addresses Lab device manufacturers to document recommended mapping of test codes and result values used on their devices using proprietary/local code systems to (inter)national vocabularies such as LOINC and SNOMED.
EMA plan to use this for representing the devices that are commonly supplied with medication items, within the same packaging (e.g., syringe, spoon etc). This "SPOR" project is currently implementing, with a first release in early 2020.
Content sources
- HL7 FHIR Device and DeviceMetrics
- HL7 V2 EQU and DEV segments
- EMA XEVPRM implementation of regulatory medications information
Example Scenarios
Ordering supplies using SupplyRequest would typically reference DeviceDefinitions rather than specific devices.
Ordering DME would typically reference DeviceDefinitions rather than specific devices.
Standard vocabulary mappings for devices typically define common mappings based on device models, thus DeviceDefinition rather than for each individual device.
Submission by a pharmaceutical manufacturer of the details of a packaged medicinal product for licencing by regulators (e.g. EMA, FDA, MHRA) would typically include definitions of the devices included (description, dimensions, materials, manufacturer etc).
Resource Relationships
- Device
- Composition
- ObservationDefinition
- PackagedMedicinalProductDefinition (contains devices as defined by DeviceDefinition)
Timelines
September 2018 inclusion in FHIR R4.
gForge Users
Eric Haas, Jose Costa Teixeira
When Resource Proposal Is Complete
When you have completed your proposal, please send an email to FMGcontact@HL7.org
