V3DAM_UDIREQ_R1_D1_2016
HL7 Version 3 Domain Analysis Model: Medical Devices and Unique Device Identification, Release 1
April 2016
HL7 For Comment Ballot
Sponsored by:
Orders and Observations Work Group
Healthcare Devices Work Group
Acknowledgments
Orders and Observations Work Group Co-Chairs:
Hans Buitendijk, Siemens Healthcare
Lorraine Constable, Constable Consulting Inc.
Patrick Loyd, ICode Solutions
Robert Hausam MD, Hausam Consulting
Ken McCaslin, Quest Diagnostics, Incorporated
Riki Merrick, Vernetzt, LLC
Modeling / Project Facilitators:
Patrick Loyd, ICode Solutions
Marti Velezis, FDA
Publishing Facilitator:
Patrick Loyd, ICode Solutions
Table of Contents
1 Executive Summary 2
2 Business Model Conceptual Artifacts 2
2.1 Business Context 2
2.2 Business Function 3
2.2.1 Basic business process use case bubble diagram 3
2.3 Conceptual Roles 4
2.4 Processes 5
2.4.1 Business Process 6
2.4.2 Medical Device Business Process 6
2.4.3 Medical Device Business Process Assumptions 7
2.4.4 Medical Device Business Process Workflow 7
2.4.5 Medical Device Business Process Workflow Narratives 8
2.4.6 Process - Create Medical Device Order 8
2.4.7 Change Medical Device Order - Process 14
3 Information Model Conceptual Artifacts 17
3.1 Conceptual Information Model 17
3.2 Conceptual Data Types Model 18
3.3 Conceptual State Model 18
3.4 Concept Domains 22
4 Solution Specification 22
4.1 Computational Viewpoint 22
4.1.1 Overview 22
4.1.2 Contract Roles and Agents 23
4.1.3 Scenario 1 - Create Lab Order 25
4.1.4 Scenario 2 - Change Lab Order 26
4.1.5 Scenario 3 - Cancel Lab Order 27
4.2 Contractual Semantics and Issues 27
4.2.1 Conformance Assertions 28
5 Computational Services 28
5.1 Order Manager 28
5.1.1 Service Description and Purpose 28
5.1.2 Scope 28
5.1.3 Reason why the service is necessary 29
5.1.4 Structure of the Service 29
5.1.5 Assumptions and Dependencies 30
5.1.6 Implementation Considerations 31
5.1.7 Detailed Functional Model for Each Operation 31
5.1.8 Profiles 35
5.1.9 Recommendations for Conformance and Compliance 35
5.2 Fulfillment Manager 35
5.2.1 Service Description and Purpose 35
5.2.2 Scope 36
5.2.3 Reason why the service is necessary 36
5.2.4 Structure of the Service 36
5.2.5 Assumptions and Dependencies 37
5.2.6 Implementation Considerations 37
5.2.7 Detailed Functional Model for Each Operation 37
5.2.8 Profiles 40
5.2.9 Recommendations for Conformance and Compliance 40
Executive Summary
· This document contains the necessary definitions, descriptions, graphics, and artifacts relevant to the development of logical and implementable artifacts for an electronic request for healthcare services between an ordering provider and a performing healthcare facility providing surgical implantation/explantation of medical devices. Specifically, this document defines the requirements for unique (global) medical device identification.
1 Business Model Conceptual Artifacts
1.1 Business Context
· The healthcare devices domain comprises the models, messages, and other artifacts that are needed to support messaging related to the use of medical devices in a healthcare context.
· Services may be delivered/executed at a external lab, an on-site lab, or at the point of care. This topic covers service requests from all locations, including bedside and in-hospital, clinic and outpatient, and lab-to-lab interactions. It includes orders accompanied by specimens to be analyzed, as well as orders for which the performing Medical Device is responsible for obtaining the specimens. Observations (results) may be generated for both ordered and unordered (e.g., POC) tests.
· Workflow includes ability of performing facility to accept, modify, or reject an order, with an appropriate indication sent back to the orderer. Modification may include addition of a unique identifier to the device record.
1.2 Scope
· The scope of this R1 release of the Domain Analysis Model (DAM) Conceptual Specification includes the electronic documentation of the lifecycle of a medical device. Specifically the request to perform an implantation/explantation, the documentation of the procedure itself, and finally an update to the EHR.
· The scope for this release does not include……
· The scope for this release does not include…….
1.3 Business Function
For this specification, the business function at its most basic is about ordering (requesting a healthcare service) and the fulfillment of that request by filling entities.
1.3.1 Basic business process use case bubble diagram
The following bubble diagram describes the ordering business process.
1.4 Conceptual Roles
1.5 Processes
1.5.1 Business Process
At its most basic, the business process documented in this use case is one of a requested service and documentation when that service is performed. M
1.5.2 Medical Device Business Process
For Medical Device Diagnostics (specimen testing), the following illustrates high-level business functions:
1. Diagnostic (or Public Health) Specimen-based Medical Device work requested for a subject (e.g., patient, animal, environmental)
2. Specimen collected from subject
Graphic here
From which a set of concepts representing the state or status of a Medical Device order can be derived.
1.5.3 Medical Device Business Process Assumptions
While the above list shows the performed steps in a basic lab ordering/fulfillment process, each of these steps may be performed by different actors/roles in any one specific process; for example, a Clinician, Medical Device Technician (e.g., phlebotomist), Investigation Team Member, the Subject (patient), or a person responsible for a Subject may collect the specimen. In addition, the steps may be performed at different locations; specimens may be collected at the point of care, at the subject's location (e.g., at a Medical Device Business Process Workflow Narratives
The following are the in-scope business workflow-specific processes:
· Create Medical Device Order
· Change Medical Device Order
· Cancel Medical Device Order
· Query Medical Device Orders
1.5.4 Process - Create Medical Device Order
1.5.4.1 Process Storyboards - Create Medical Device Order
1.5.4.1.1 Storyboard (Universal) - Implantation of a New Device (Initial/First Device)
Eve Everywoman, a ,,,, Create narrative
UC#5.1.1 Provider orders the New Device for Patient A (DI)
• Provider obtains Device Identification (DI) number for device needed for Patient A
• Provider checks materials management system for device
• Provider places order for device in the Inventory management system
UC#5.1.2 Provider performs implant procedure of medical device(s) in the patient (first implant)
• A new device(s) implanted as ordered
• UDI(s) is/are scanned into Inventory Management system
• UDI elements are recorded in the procedure documentation system
UC#5.1.3 Provider documents the first time implant
• UDI recorded in Patient's Electronic Health Record for all devices and their accessories (e.g., screws, fastners, leads, etc.) and all other pertinent information (e.g., location of device, observations, and other clinically relevant parameters)
• Hospital sends updated health record with implantable device list to care provider (s)
• Care provider(s) receive initial implantable device list
Documentation Pathways
• Hospital/system sends device list to the patient's care provider list (e.g., referring physicians, primary care physicians, etc)
• Patient's Electronic Health Record is available for query by external providers; need to determine what is availble in these queries - the device list and/or other information about the patient's procedure (i.e., other relevant information - e.g., intolerances or reasons for implantation or explantation).
UC 5.2 -
This list functions appears to imply that creating a device list is a stand-alone activity. It may actually happen in two steps:
this may not be a stand-alone but the device list may be the outcome of other activities:
ordering a device for a procedure
first we order a generic "Coated femoral stem prosthesis, modular"
second, perhaps, we look up and order a device using DI for a specific brand name "Rocky Mountains Hip System" and model number "model 3000" from vendor "Denver Inc." corresponding to a device we have already in an inventory system?
performing a procedure with ordered medical device
third we perform the procedure in which the hip was implanted and we add the PI for the "Coated femoral stem prosthesis, modular" supplied by "Denver Inc." under the brand name of "Rocky Mountains Hip System" with a DI 0000333000 (fake GS1)
documenting the procedure and implant of medical device
fourth we document the procedure and add the screws and cement that was actually used with the hip implant.
this part of the procedure documentation will "add" to the patient's existing device list a new hip implant (the patient may already have an implanted defibrillator)
.
1.5.4.1.2 Storyboard (Universal) – Replace Medical Device
Create narrative
UC# 7.1 Patient is scheduled to replace a previously implanted knee implant that does not have an existing UDI 20 years ago
"UC#7.1.1 Provider orders replacement medical device
• Provider obtains Device Identification (DI) number for device needed for Patient A
• Provider checks materials management system for device
• Provider places order for device in the Inventory management system"
"UC#7.1.2 Provider performs procedure to replace medical device
• Previous device explanted. Update UDI status in Patient's Electronic Health Record. Need to understand state changes.
• New device implanted. "
"UC#7.1.3 Provider performs procedure to replace medical device
• Replacement UDI recorded in Patient's Electronic Health Record
• Hospital sends updated health record with implantable device list to care provider (s)
• Care provider(s) receive updated implantable device list"
1.5.4.1.3 Storyboard (Universal) – Explant Medical Device
In some countries there are services separate from the provider or lab who travel to each patient in order to perform specimen collection.
Eve Everywoman, a 27-year-old female, create narrative
"Use case: Will there ever be an explant that is not replaced? I.e., the device is just explanted and nothing is put in its place? I believe that there are instances of this.
• Hospital obtains Patient's Electronic Health Record to confirm that it includes the implantable device on the Device List
o If not recorded – should it be recorded as existing?
o If it is recorded – it will need to be updated after it is replaced
• Previous device explanted. Update UDI status in Patient's Electronic Health Record.
• Hospital sends updated health record with implantable device list to care provider (s)
• Care provider(s) receive updated implantable device list (which includes the status of previous? Or just the removal of the device from the list)
"
1.5.4.2 Process Description - Create Medical Device Order
Patient Pre
1.5.4.3 Process Actors - Create Medical Device Order
Primary/Secondary / Human/System / Name / DescriptionPrimary / Human / Subject/Patient / Role which represents one of:
· 1) an entity seeking healthcare services, or
· 2) an entity from which a specimen was obtained. For most care settings, this is a patient. For public health, subject is a more apt descriptor, or
· 3) an entity existing in healthcare for which administrative tasks are performed (e.g. cleaning a patient room)
Primary / Human / Provider / Role which provides some type of added value to healthcare services. This includes the care providers as well as non-care providers.
Primary / System / Ordering System / Any computer system at the Provider's Point-of-Care used to capture and exchange healthcare information.
Primary / Human / Specimen / Role representing any material obtained from a subject for the purpose of Medical Device testing.
Primary / System / Medical Device Information System / Any computer system in the Medical Device used to capture and exchange Medical Device information.
Primary / Human / Medical Device Technician / Role for the persons who perform the testing processes on the specimen and document the outcomes.
1.5.4.4 Process Scope - Create Medical Device Order
A healthcare provider needs specimen-based diagnostic testing on a patient. This is the initial request; no request has previously been communicated for the same service at the same date/time.
1.5.4.5 Process Event Flow - Create Medical Device Order
Below is the event flow for Create Medical Device Order which defines the necessary activities, decisions, and information exchange points. The Medical Device Order Repository needed for the 3rd storyboard above is handled via an alternate flow and is not represeted in the diagram below.
Medical Device Identification Conceptual Specification R1 Page 19
April 2016 © 2016 Health Level Seven International. All rights reserved.
Medical Device Identification Conceptual Specification R1 Page 19
April 2016 © 2016 Health Level Seven International. All rights reserved.
1.5.4.6 Process Alternate Flows - Create Medical Device Order
· Alternate Flow 1
o Description: Order Repository
o In order to deploy ordering to a region, vs. a single facility or set of facilities, an architecture which includes a repository is common. This alternate flow includes the deltas from the main flow to accomodate changes necessary to the workflows when a regional order repository is used.
o Details: TBD next version
· Alternate Flow 2
o Description: Specimen Problems not resulted
o If the specimen has been determined to be unsuitable for testing, the performing Medical Device contacts the ordering provider. It is a current assumption of this use case that the communication of unsuitable specimen(s) is performed using a result.
o Details: TBD next version
1.5.4.7 Process Pre-Conditions - Create Medical Device Order
· User has create functionality and permissions
1.5.4.8 Process Post-Conditions - Create Medical Device Order
Medical Device order requestor (placer) is satisfied that the Medical Device performed the tests as requested within the current conditions and has documented and communicated those results to the order requestor.
1.5.4.9 Process Special Requirements - Create Medical Device Order
None identified.
1.5.4.10 Process Extension Points - Create Medical Device Order
None identified.
1.5.4.11 Process Business Rules - Create Medical Device Order
2 Information Model Conceptual Artifacts
2.1 Conceptual Information Model
The following classes were derived from the storyboards and use cases.