Difference between revisions of "201801 Medical Device and Implantables Tracking using UDI"
Line 8: | Line 8: | ||
=Medical Device and Implantables Tracking using UDI= | =Medical Device and Implantables Tracking using UDI= | ||
− | [ | + | [http://wiki.hl7.org/images/1/15/FHIR_Connectathon_Track_Orientation_-_Medical_Device_and_Implantable_Tracking_with_UDI.pdf FHIR Connectathon Track Orientation - Medical Device and Implantable Tracking with UDI.pdf ] |
==Goals== | ==Goals== |
Latest revision as of 20:18, 21 February 2018
Medical Device and Implantables Tracking using UDI
FHIR Connectathon Track Orientation - Medical Device and Implantable Tracking with UDI.pdf
Goals
This track is validating the use FHIR STU3 resources to:
- Record device UDI at the point-of-care and share it with enterprise systems
Record accurate information about implants (e.g. orthopedic, cardiac) and prosthetics recorded at the point-of-care (e.g. during a procedure)
- Record the Start/end Point-of-care Procedure - at the point-of-care, to avoid documentation errors
- Record Implant Procedure in EHR
- Update inventory system
- Make UDI available to ancillary systems
- Leverage FHIR “search” Application Programming API to lookup device UDI for a variety of purposes
- Use UDI for outcome analysis
- Product recalls
- Patient safety events
Project/Implementer Group
This track provides a set of simple test cases for Tracking Medical Devices (i.e. diagnostic, therapeutic, monitoring) and Implantables (biologics/tissue/cells and non-biologics/life-supporting/life-sustaining) at point of care addresses current problems relate to information accuracy including procedure-related context. This track specifies test cases related FHIR STU3 Procedure (using three PMDT-specific profiles) and FHIR Device resources (one PMDT profile) used to report information from the point-of-care to enterprise system consistent with the IHE PCC Point-of-care Medical Device Tracking Supplement.
Justification
- Implantable medical devices are costly and concerns about illegitimate (i.e., counterfeit, stolen) products has become a global issue
- By 2021 all medical devices that may be used in a point-of-care procedure will be labeled using FDA UDI that will also relate to software/firmware release
- Post-market surveillance of implantable medical devices can be challenging
- Implantable medical device adverse events and recalls pose a patient safety issue
- Acquiring medical device data used at the point-of-care is difficult to retrieve for reuse at a later time
- A consistent device identification scheme closes the loop on data acquisition at the point-of-care to support reporting of medical device data
- Medical device data used for:
- Continuum of care (e.g., Discharge Summary, Referrals)
- Registries (e.g., Total Joint Registry)
- Payers (e.g., government provided, private insurance)
- Can associate a medical device used for monitoring a disease or symptom of a disease (e.g., vital sign monitors, pulse oximeters, blood glucose monitors) to a patient for querying the device or procedure using the UDI
- Increase patient safety
- Traceability of medical devices (avoid use of counterfeit or illegitimate products)
- Quality issues identified (e.g., recalls, adverse events)
- Increase accurate medical device data capture at the point-of-care
- Eliminates human error from manual medical device data entry
Track Lead
Ioana Singureanu, VA/BZI, Skype: ioanasingureanu
Actual Participants
- HealthLX "Medical DeviceTracker" including Medication, MedicationAdministration
- VHA MDIA "Medical Device Tracker"
- SAMHSA OCP BHITS "Medical Device Server": https://ocp.consent2share.org/fhir/baseDstu3 (HAPI FHIR release "3.0.1")
- You can browse the resources you've created at :https://ocp.consent2share.org/fhir/home?encoding=null&pretty=true
This server is using and HAPI FHIR server software and a PostgresSQL database.
Roles
The test roles for this track are based on the IHE PCC PMDT Actors below:
Point-of-Care Medical Device Reporter
- Point-of-care client; it registers medical device, creates/updates point-of-care procedure information, query patient based on identifier scanned at the point-of-care. This role is played by a system used to track information about medical devices used at the point-of-care. The device and procedure information are populated at the point-of-care using scanned (AIDC) UDI and patient identifier to simplify the accurate tracking of this information.
Medical Device Server
- FHIR server, exposes Device, Procedure - references Patient. It is used to persist device and procedure information originating at the point of care. This information is made available to other information systems in the enterprise. This role may be played by a Medical Device Registry or an EHR system.
Point-of-Care Medical Device Requester
- This role is played by any information system that requires to compile an implantable device list for patient, evaluate outcomes based on device type (i.e. DI), respond manufacturers' recalls, and address patient safety events.
Scenarios
The following is a summary test cases proposed for
- Register (create) device record using
- UDI and DI only
- UDI and DI and optional attributes
- Start procedure at the point of care. This may an infusion procedure, a diagnostic procedure using a device, a monitoring session, etc. The Procedure resource specifies the status as "in-progress" and the start of the procedure as well as the coded procedure type, patient, practitioner, etc. At the minimum the patient, the device, and the practitioner known at the point-of-care should be specified.
- with externally referenced device
- Complete procedure; it marks its status to "completed" and specifies the time it was completed.
- with externally referenced device
- Complete implantable procedure; this a one-time record that a device, tissue, or tissue products was implated.
- with externally referenced device; it assumes the device was already registered and its UDI and its other identifiers were captures.
- with contained device reference; the device information is included as "contained" resource in the Procedure.
- Search procedures; to compute outcomes, compile implantable device lists for transition-of-care, to respond to recall notifications
- by patient
- by other optional search parameters
- Search devices; to track device utilization, for quality control, to compute outcomes, compile implantable device lists for transition-of-care, to respond to recall notifications
- by udi-carrier
- by patient
- by udi-di
Register Medical Device or Implantable from the point-of-care
- Action: The 'Tracker' creates a
Device
resource (using PUT/update), setsDevice.id
to a 'GUID',Device.udi.carrierAIDC
to the base64-encoded, 'scanned UDI', setsDevice.status
to 'active'. TheDevice.patient
references is set to external reference previously retrievedPatient
resource. (see 'Precondition'). - Precondition: The 'Tracker' queried the
Patient
resource using thePatient.identifier
scanned at the point-of-care. This external references is used inDevice.patient
. - Success Criteria: The 'Requester' queries
Device
by 'udi-carrier' (expression:Device.udi.carrierHRF | Device.udi.carrierAIDC
) and retrieves one matching resource containing the correct information. The 'Tracker' can retrieve it by logical id/GUID. - Bonus point: specify optional data elements (S, 0..) of the
Device
resource.
Complete an Implantable Procedure
- Action: The 'Tracker' creates a
Procedure
resource (using PUT/update), sets theProcedure.id
to a GUID,Procedure.status
to 'completed',Procedure.focalDevice.manipulated
to reference the device registered above. The 'Tracker' set theProcedure.performedDateTime
to the current date/time. The 'Tracker' specifies theProcedure.code
corresponding the implant procedure performed. - Precondition: The 'Tracker' queries the
Patient
resource using thePatient.identifier
scanned at the point-of-care. The 'Tracker' registered a medical device or implantable using a pre-defined GUID as its logical identifier. - Success Criteria: The tracker can retrieve the
Procedure
resource using its _id. The 'Requester' queriesProcedure
based on the Patient reference. - Bonus point: The 'Requester' searches the
Procedure
resource based onProcedure.code
(expression:code
).
Start a Point-of-Care Procedure
- Action: The 'Tracker' creates a
Procedure
resource (using PUT/update), sets theProcedure.id
to GUID,Procedure.status
to 'in-progress',Procedure.focalDevice.manipulated
to reference the device registered above. The 'Tracker' set theProcedure.performedPeriod.start
to the current date/time. - Precondition: The 'Tracker' queries the
Patient
resource using thePatient.identifier
scanned at the point-of-care. The 'Tracker' registered a medical device or implantable using a pre-defined GUID as its logical identifier. - Success Criteria: The tracker can retrieve the
Procedure
resource using its _id. The 'Requester' queriesProcedure
based on the Patient reference. - Bonus point: The 'Requester' searches the
Procedure
resource based onProcedure.code
(expression:code
).
Complete a Point-of-Care Procedure
- Action: The 'Tracker' updates the
Procedure
resource (using PUT/update), it sets theProcedure.id
to its previously set GUID,Procedure.status
to 'completed',Procedure.focalDevice.manipulated
to reference the device registered above. The 'Tracker' set theProcedure.performedPeriod.end
to the current date/time. The 'Tracker' specifies theProcedure.code
corresponding the implant procedure performed. - Precondition: The 'Tracker' queries the
Patient
resource using thePatient.identifier
scanned at the point-of-care. The 'Tracker' registered a medical device or implantable using a pre-defined GUID as its logical identifier. The 'Tracker' created a first version of theProcedure
- Success Criteria: The tracker can retrieve the
Procedure
resource using its _id. The 'Requester' queriesProcedure
based on the Patient reference. - Bonus point: The 'Tracker' submits the same transaction using references to the
Practitioners
involved in the procedure.
Search Devices by UDI, based on associated Condition,
- Action: The 'Requester' retrieves the
Device
resources using the device identity (DI and lot number) as well as the Condition of the patient. Thesearch
API allows the Requestor to create composite searches that search devices by DI/PI and by an associatedCondition.code
and return the patients who match the composite search.
[https://www.hl7.org/fhir/search.html FHIR Search Application Programming Interface - API ), it sets the
- Success Criteria: The "Requester" can retrieve the
Device
resource based on Device DI and lot number - Bonus point: The "Requester" can retrieve the
Device
resource based on Device DI and lot number and by patient's Condition.
TestScript(s)
- TestScript resources will be created/registered for September 2018 FHIR Connectathon
January 2018 Connectathon Outcomes
Goal
- To use FHIR to record information about procedures performed at the point-of-care using medical devices (single-use, implantable, monitoring) and record the procedure (e.g. implant, monitoring), identity of the device(s) (e.g. UDI), references to patient, providers,etc.
This track was intended to validate the FHIR profiles developed to supproto the "Point-of-care Medical Device Tracking" (PMDT) integration profile developed by VA and AORN (Asssociation of PeriOperative Nurses) as an IHE Patient Care Coordination Technical Framework supplement.
Participants
- Ioana Singureanu, VHA (Track Lead)
- John Rhodes, Philips Medical Systems
- Stephen Hollifield, HealthLX
- Will Tesch, HealthLX
- Richard Esmond, PenRad
- Greg Gustafson, PenRad
Notable Achievements
- In addition to testing out the Device and Procedure resources we also tested Medication, MedicationAdministration, and Location to support the requirements of a new IoT device. The personal injection device is intended to record and transmit the identity of the operator, the geolocation (using Location), the type, route, and medication dose (using Medication and MedicationAdministration).
- We discovered these resources could be used with RFID tagged devices - using a needle application or could molded into a larger device to provider RFID for the larger implant. The metal alloys used in devices are carefully research to avoid impact on future diagnostic imaging (avoid shadows and echos).The UDI could be used to track devices to the unique id of tumor and share the id of the tumor over time, among various system.
Screenshots
- Not applicable at this time; this specification is meant to enable automatic data capture of identities, procode time, and location.
- Some implants can identity location of a lump and provide RFID:
Discovered issues
- We need to track the a tumor (using a unique id) across systems, over a period of time as treatment are applied to the site. Can we use BodySite to represent a tumor and "treat" the body site?
- We decided to use "Medication.supportingInformation" to specific a Location reference for the place where the device was used to self-deliver medication (e.g. chemo, insulin).
Next Steps
- We will add "MedicationAdministration", "Medication", and "Location" to the set resources and profiles we could use to document point-of-care procedures.