Skip to end of metadata
Go to start of metadata

Agenda

  • Approve (minutes from previous meeting)

Attendees

  • Lloyd McKenzie (chair)
  • Craig Newman
  • Vassil Peytchev
  • Riki Merrick (scribe)
  • Bas van den Heuvel
  • Kathy Walsh
  • Dan Rutz
  • John Hatem
  • Jose Costa Teixeira
  • Oliver Krauss
  • Reinard Egelkraut
  • JD Nolen
  • Todd Johnson
  • Ricardo Quintano
  • Lorraine Constable
  • Rob Hausam
  • Reinhard Egelkraut

Minutes Approval

Specimen Workflow

  • In V2 to FHIR mapping from Specimen DAM – how to handle move and processing of specimen
  • What to use when
    • Move between places
    • Change specimen – e.g. aliquoting, creating blocks an slides
    • Protocol related steps
  • Look at specimen minutes from 7-20-2020
    • For the decision tree document there are new links, but not so helpful for solving this particular problem
      • This came up that a lab that receives a serviceRequest if that is actionable, or if it needs a task
        • There is guidance around that
      • Are we missing a resource?
        • Procedure with the current scope doesn’t fit for just the movement
        • We ruled out use of provenance, because that documents what happened to the data, not a physical thing
        • Task does not have to be tied to ServiceRequest, but can be
          • Task is about linking the request for something to be actioned (sometimes you need more than just knowing it is done)
        • Use event resource?
          • How to decide which one to use?
        • Procedure resource is the documentation of what happened – may have a serviceRequest (authorization of what needs to be done) that is documented as a procedure (what has been done)
          • Specimen collection
          • Specimen processing (like block and slide creation) based on a protocol
          • An have more than one task for a single ServiceRequest (if detail around the sub steps is not needed)
          • Want to avoid use of task input to document this kind of detail
        • We need to pull this out of the entire order- result workflow and JUST look at what happens to the specimen specifically
          • Have stand alone request
            • Have task that pints to the request (can scope the request more)
          • Can have task with a contained request – so cannot be pointed to by other tasks
          • Stand alone task, no linkage to any request
        • Can you have ServiceRequest as stand-alone that is actionable?
          • Yes for documentation purposes only, unless
            • Add a tag on ServiceRequest
            • Send task that points to the ServiceRequst
            • Create operation that references or the ServiceRequest could be a parameter in an operation
            • Use messaging to pass the ServiceRequest, but it is still netter to include the task in the message, so that you can share the status of the order during its lifecycle
          • For lab workflow must support
            • Asking questions
            • Allow for cancellations
            • Allow for refusal
              • Because of this should not use ServiceRequest with a tag
              • So use task to communicate acceptance, refusal etc.
              • The authorization of what to do never changes until the author of the ServiceRequest is happy with the outcome and sets the status to completed
            • For internal lab workflows use of ServiceRequest for each little step may be too much overhead
              • Use task to track did it happen, and where is it in the workflow state
              • Task can reference both the authorization as well as the protocol step of what is
              • If you need to define the detail that is happening
                • If code is enough, then use task as subtask
                • If detail is needed then
              • For transport should consider new resource
                • Specimen (OO)
                • Patient (PC and PA)
                • SupplyDelivery (OO)
                • Need to work with PA and PC
                  • How are supply and patient transport being ordered?
                    • Is it distinct from regular order, so can we re-use ServiceRequest
                  • May need authorization for transport
                  • Detail
                • There may be times, when you don’t need an authorization for specimen move at the detail in the lab-automation, but may need to describe from where to where at what time etc.
                • Task does not have that kind of detail
                • So may need 2 resources:
                  • TransportEvent
                  • And maybe TransportRequest – or can these capabilities be added to ServiceRequest – and boundaries to the SupplyRequest resources
                • How do find out where the specimen is now?
                  • Reference location in the encounter shows where the patient is/was
                  • Details about how the transport went, use the TransportEvent resource
                • Would a request to use an Ambulance to move the patient to a different location
                  • ServiceRequest
                  • TransportRequest
                  • Encounter (patient with paramedic) – for example at site of accident when care is provided


Is it a Procedure, Task, something else?

How do we handle 'moving' something?

In general a completed Task will have an 'Event' resource that represents the action that completed it - though it's possible that Event resource won't be manifested.

On the Request side, it's possible to have just a Task that defines what is to happen without a stand-alone Request instance, however Task can't convey much nuance in terms of "what is to be done" other than code.

3 patterns:

  • Request + Task asking for fulfillment
  • Task asking for fulfillment of contained Task
  • Task on its own

Recommendation to define a new Transport resource as a new type of Event.  May also need to explore a new TransportRequest - will need to decide whether this a distinct resource vs. enhancing ServiceRequest.  Will need to define relationship between these and Supply/SupplyRequest.  Also note relationship with Encounter (for location tracking).

Actions:

  • Workflow will write up a guidance on two things:
    • When is a Request needed in conjunction with Task and when can it stand alone
    • For Events, when is it appropriate to have just Task and when does a corresponding Event resource
  • OO will pursue discussion w/ PA, PC and whoever else appropriate around the introduction of a TransportEvent and possibly TransportRequest resource
    • Start this under the specimen PSS

Other business

  • No calls for next 2 weeks.  Will resume on Aug. 24
  • Discussion w/ Kathleen about Contract state machine will be scheduled for Aug. 24th call

Adjournment

15:01 Eastern