Stream: implementers
Topic: Transportation Service
Radu Craioveanu (Jul 16 2019 at 19:22):
has anyone modeled a Transportation service on FHIR. A Location whould offer a Transportation Service. A Provider would order Transportation for a patient (based on Benefits Investigation and electronic Prior Auth, Claim). What would you use to model a Transport pickup, destination, type of vehicle, pickup schedule, drop off schedule, transport status - ordered, in-progress, arrived, canceled....? The Transport may be recurring or one time, one way or two way.
Lloyd McKenzie (Jul 16 2019 at 19:27):
I think that's currently a gap in the existing resources. @Eric Haas @Michelle (Moseman) Miller ?
Eric Haas (Jul 16 2019 at 19:36):
@uber @lyft?
Eric Haas (Jul 16 2019 at 19:51):
(that was lame attempt at humor) I think this is important. maybe we can discuss on next PA call?
Lloyd McKenzie (Jul 16 2019 at 19:51):
@Brian Postlethwaite
Eric Haas (Jul 16 2019 at 19:53):
oops I meant PC call. I think on the ordering end is ServiceRequest. Not sure what the represents the service?
Eric Haas (Jul 16 2019 at 19:55):
Procedure?
Lloyd McKenzie (Jul 16 2019 at 19:57):
My guess is we're going to need a specific resource for this, though it might be possible to handle it through existing resources + extensions. One of the things to evaluate is how existing systems that manage requests for transport and records of transport manage such data in their current software.
Jose Costa Teixeira (Jul 16 2019 at 20:08):
Common case for transport is in supply chain.
Jose Costa Teixeira (Jul 16 2019 at 20:09):
I presume we are talking about patient transport in this case, but should we have a patient transport service and leave out transport of stuff?
Eric Haas (Jul 16 2019 at 20:12):
I assumed patient too
Jose Costa Teixeira (Jul 16 2019 at 20:13):
i agree, just wanted to say that supply chain is perhaps not in the 80% of the transport cases. So we should do this for patient, but if we do it right, we could have something we can reuse for stuff in those <20% of cases
Lloyd McKenzie (Jul 16 2019 at 20:36):
Agree that the solution should work for transport of organs, specimens, records and other things too.
John Moehrke (Jul 17 2019 at 14:50):
IHE has a profile for this use-case. Mapping a common dataset defined by the transport community into a FHIR document (Composition). https://wiki.ihe.net/index.php/Routine_Interfacility_Patient_Transport
John Moehrke (Jul 17 2019 at 14:51):
A similar for EMT use-case https://wiki.ihe.net/index.php/Paramedicine_Care_Summary
John Moehrke (Jul 17 2019 at 14:53):
All IG are registered in the IG Registry at http://www.fhir.org/guides/registry/
Radu Craioveanu (Jul 17 2019 at 19:57):
I will checkout the IHE model... If it fits well, what would it take for it to be implemented in FHIR?
Jose Costa Teixeira (Jul 17 2019 at 20:13):
AFAIK, RIPT deals with information needed "before transport" or information that should be ready for the patient when the patient undergoes transport.
Jose Costa Teixeira (Jul 17 2019 at 20:13):
@John Moehrke can you confirm?
Jose Costa Teixeira (Jul 17 2019 at 20:14):
@Radu Craioveanu if so, this is not the same as you seem to be looking for. we would need something for transport itself which we do not have.
John Moehrke (Jul 17 2019 at 20:19):
@Radu Craioveanu the IHE Profile is an Implementation Guide (IHE has for 20 years called them Profiles)
John Moehrke (Jul 17 2019 at 20:19):
The IHE profile has both CDA and FHIR forms, with cross-reference between them
John Moehrke (Jul 17 2019 at 20:21):
It is the information that is communicated when a patient is transported.
John Moehrke (Jul 17 2019 at 20:23):
The FHIR Conformance resources are not yet published (the normative specification is the human readable narrative). I expect them to happen this year.
John Moehrke (Jul 17 2019 at 20:24):
Ill ask the author what the status of the FHIR conformance resources are.
Lloyd McKenzie (Jul 17 2019 at 20:34):
What resources does it use for "request for transport" and "performed transport"?
Jose Costa Teixeira (Jul 17 2019 at 21:01):
it doesn't
Jose Costa Teixeira (Jul 17 2019 at 21:02):
at least i do not see them in the profile. hence my point. This IHE profile is not about transporting, it is about getting the right information ready so that when the patient disembarks, the other care givers can do their thing
Jose Costa Teixeira (Jul 17 2019 at 21:03):
Jose Costa Teixeira (Jul 17 2019 at 21:04):
a propos, this ihe profile comes with a warning:
Jose Costa Teixeira (Jul 17 2019 at 21:04):
4. There is a FHIR resource gap for Transport instructions
Jose Costa Teixeira (Jul 17 2019 at 21:06):
The message is a FHIR HTTP or HTTPS GET of Transport Data where the parameter provided is the Patient.id with an option to ask for a specific version of the current information needed for patient transport. Since this is retrieving from multiple resources the URLs for this operation are:
• [base]/Patient/[id]
• [base]/RelatedPerson/[id]
• [base]/Coverage/[id]
• [base]/Practitioner/[id]
• [base]/Claim/[id]
• [base]/AllergyIntolerance/[id]
• [base]/Procedure/[id]
• [base]/Immunization/[id]
• [base]/MedicationStatement/[id]
• [base]/ClinicalImpression/[id]
• [base]/DiagnosticOrder/[id]
• [base]/DiagnosticReport /[id]
• [base]/ImagingStudy /[id]
• [base]/Observation/[id]
• [base]/Condition/[id]
• [base]/Location/[id]
Jose Costa Teixeira (Jul 17 2019 at 21:06):
So it does not apply for transportation requests or events.
John Moehrke (Jul 17 2019 at 21:29):
Correct, it is not a request to transport... It covers the current process of medical relevant paperwork that goes along with the patient. There was not an ask to cover the workflow of requesting that a transport be done.
Radu Craioveanu (Jul 17 2019 at 21:35):
right, the data listed will allow the Transport / Ambulance Provider to provide care and be able to bill the insurance company. This looks like a superset of what we need to send to the Transport Provider. They use the Location address and Patient address to prefil the pickup and drop off location. We are able to pull all the info from our FHIR server (HAPI).
I am pasting the params required by the current API with the Tansport Provider. I would like to ultimately be able to map everything in FHIR on our side, so us, as a Provider, can have all the data in FHIR.
The API allows us to 'Create a new request for transport' and the response is the same as the request, plus a unique trip ID. The Request can be read again for changes (GET/trip ID), update with changes (PUT or PATCH). There is also an ability to get callbacks on
❍ coverages (optional): An array of coverages in order (offset 0 is primary, offset 1 is secondary, etc)
❍ authorization_number (required): Authorization number for this coverage
❍ payer (required): Payer name for this coverage
❍ policy_number (required): Policy number for this payor
● destination_place (required): Destination of transport
❍ address (required): Address of destination
❍ city (required)
❍ country (required)
❍ postal_code (required)
❍ state (required)
❍ street1 (required)
❍ street2 (optional)
❍ name (optional): Facility name of destination
● estimated_drop_off_seconds (optional): Estimated seconds it will take to drop off the patient
● estimated_pick_up_seconds (optional): Estimated seconds it will take to pick up the patient
● er_bound (optional, default false): Is the destination facility an emergency room?
● lights_and_sirens (optional, default: false): Should the unit run code 3 with lights and sirens?
● patient (required):
❍ chief_complaint (required): Primary reason for transport
❍ date_of_birth (required)
❍ first_name (required)
❍ height_meters (optional)
❍ bed_bound (required): Is the patient bed bound?
❍ requires_oxygen (required): Does the patient require oxygen?
❍ last_name (required)
❍ middle_name (optional)
❍ weight_kilograms (optional)
● pick_up_instructions (optional): Specific pick up instructions
● pick_up_place (required): Origin of transport
❍ address (required): Address of origin
❍ city (required)
❍ country (required)
❍ postal_code (required)
❍ state (required)
❍ street1 (required)
❍ street2 (optional)
❍ name (optional): Name of pick up facility
❍ room_number (optional)
● requested_on_scene_time (required): iso-8601 target time.
● requester (required): Person making the request for transport
❍ first_name (required)
❍ last_name (required)
❍ phone (required)
● requester_agency (required): Agency making the request
● required_equipment (optional): List of required equipment
● required_personnel (optional): List of required personnel
● round_trip (optional): Round trip details
❍ estimated_wait_time_seconds (required): Estimated time at destination
❍ wait_required (required): Does the unit need to stay with the patient at destination?
● service_level (required): Service level for the transport
Jose Costa Teixeira (Jul 18 2019 at 04:02):
The resource for this (transport request) does not exist yet. The information in RIPT can be a superset of the information you need, but this is independent from having a Transport resource
Last updated: Apr 12 2022 at 19:14 UTC
