Difference between revisions of "FHIR Resources for MMM"

From IHE Wiki
Jump to: navigation, search
(Functional resources – transaction content)
 
Line 2: Line 2:
  
 
== Functional resources – transaction content ==
 
== Functional resources – transaction content ==
 +
 +
Step 1: asking the server for relevant medication requests
  
 
# Search medications for a patient: medicationRequest  http://build.fhir.org/medicationrequest.html  
 
# Search medications for a patient: medicationRequest  http://build.fhir.org/medicationrequest.html  
Line 10: Line 12:
 
### Status = Active
 
### Status = Active
 
### '''OPEN:''' Nurse=<...>
 
### '''OPEN:''' Nurse=<...>
### medicationRequest.intent="instance-order" '''<-- this is agreed but needs to be in FHIR. 12446 and 12379 submitted.'''
+
### medicationRequest.intent="instance-order" '''<-- RESOLVED
#### Do we support that the nursing app does the "encoding" from BID to "one at 9, another at 15h00"???
+
#### Do we support that the nursing app does the "encoding" from BID to "one at 9, another at 15h00"??? Decision (5th Jan 2017): NO
  
 +
Scenario: Prescription says "2x a day"
 +
 +
Option 1: Nurse gets ONE request containing "drug X, twice a day"
 +
'''Option 1 is out of scope. As a consequence, EACH DRUG ADMINISTRATION REQUESTS ITS OWN ORDER. See option 2'''
 +
Option 1.1: Nurse stays with the patient (possibly two rounds) and has 2 administration events
 +
Option 1.2: Nurse gives medication to the and registers that event
 +
 +
Option 2: Nurse gets TWO requests:"drug X,  9 am" "drug X,  3pm"
 +
This is supported.
 +
 +
Step 2: server sends medication requests
 
# GET medicationRequests for today
 
# GET medicationRequests for today
 
## The response is several MedicationRequest resources:
 
## The response is several MedicationRequest resources:
Line 45: Line 58:
  
  
HOW TO support partial administration?  Suggestion: We use administration to document every event in the administration (e.g. change of bag, change of nurse).
+
Do we support partial administration?  Decision: To consider, but later. This has surely consequences in administration event, and in some rare cases it can also be in the medicationRequest (e.g. tithered or phased infusions).
 +
We can use administration to document every event in the administration (e.g. change of bag, change of nurse).
  
 +
Step 3: After performing, report administration
  
# Send report of administration: medicationAdministration http://build.fhir.org/medicationadministration.html  
+
# medicationAdministration http://build.fhir.org/medicationadministration.html  
 
## Must include non-administrations, as well as other information
 
## Must include non-administrations, as well as other information
## Do we include perfusion administration?
+
## Do we include perfusion administration? Later we give examples.
## Do we need to differentiate already-dispensed medication with to-be-dispensed medication? Suggestion: perhaps we later have to append a “dispense” resource.
+
## 3 cases differentiate  
## Later: Delivery and not administration (supplyDelivery? Dispense?)
+
### already planned and assigned medication - as above (this is the patient's Baxter strips)
 +
### PRN medication that has been ordered for a patient
 +
#### Patient-stock - patient already has the medication in a baxter strip or at home - This is the same as above (the only difference is transport) - nurse registers the medicationAdministration.
 +
#### No patient stock - OUT OF SCOPE for now
 +
### Unplanned administration from nurse's emergency box
 +
#### We should support this clinically, i.e. the nurse can still register an administration without an order.
 +
 
 +
 
 +
## Later: Delivery and not administration (This has been discussed and is a Dispense/transport event)
 +
 
 +
What happens the next day?
 +
Administration?
 +
Statement?
 +
 
 +
Before addressing this, we should ask nurses about what is the practice.
 +
 
 
## Later: consume 2 items to administer only 1.
 
## Later: consume 2 items to administer only 1.
  
Line 62: Line 92:
  
  
 +
 
  
 
 
 
 
 
== Technical transport: How to get information from server to client ==
 
== Technical transport: How to get information from server to client ==
 
# Option 1: REST PULL
 
# Option 1: REST PULL

Latest revision as of 05:53, 5 January 2017

FHIR resources for MMA

Functional resources – transaction content

Step 1: asking the server for relevant medication requests

  1. Search medications for a patient: medicationRequest http://build.fhir.org/medicationrequest.html
    1. Must have a specific parameter (medicationRequest.intent or other) to select only the lists of administrations planned, not the prescriptions and encoded orders, etc.
    2. Search criteria:
      1. OPEN: Date/time of administration=<...> <-- this should be in dosageInstruction.???
      2. Patient=<...>
      3. Status = Active
      4. OPEN: Nurse=<...>
      5. medicationRequest.intent="instance-order" <-- RESOLVED
        1. Do we support that the nursing app does the "encoding" from BID to "one at 9, another at 15h00"??? Decision (5th Jan 2017): NO

Scenario: Prescription says "2x a day"

Option 1: Nurse gets ONE request containing "drug X, twice a day" Option 1 is out of scope. As a consequence, EACH DRUG ADMINISTRATION REQUESTS ITS OWN ORDER. See option 2 Option 1.1: Nurse stays with the patient (possibly two rounds) and has 2 administration events Option 1.2: Nurse gives medication to the and registers that event

Option 2: Nurse gets TWO requests:"drug X, 9 am" "drug X, 3pm" This is supported.

Step 2: server sends medication requests

  1. GET medicationRequests for today
    1. The response is several MedicationRequest resources:
      1. Identifier = XXX
      2. Definition (if there is a protocol, but not now)
      3. BasedOn: Pointer to prescription/plan
      4. Requisition: the multiline prescription to which each prescription belongs
      5. Status = active
      6. Stage: “instance-order”
      7. Medication: each medication
      8. Patient: patient resource
      9. Context: encounter / ????
      10. SupportingInformation (none?)
      11. dateWritten: when it was decoded
      12. Requester:
      13. reasonCode: the indication or diagnosis
      14. reasonReference: a pointer to a condition or observation
      15. note: administration notes
      16. category: outpatient or inpatient
      17. dosageinstruction.
        1. Sequence=?
        2. Text=??? (we must clarify how this differs from the Notes above)
        3. additionalInstructions=?
        4. Timing
          1. event = 13:00 or
          2. When = lunch
        5. Site
        6. Route
        7. Method
        8. Dose.doseQuantity=1
        9. Maxdoseperadministration=1


Do we support partial administration? Decision: To consider, but later. This has surely consequences in administration event, and in some rare cases it can also be in the medicationRequest (e.g. tithered or phased infusions). We can use administration to document every event in the administration (e.g. change of bag, change of nurse).

Step 3: After performing, report administration

  1. medicationAdministration http://build.fhir.org/medicationadministration.html
    1. Must include non-administrations, as well as other information
    2. Do we include perfusion administration? Later we give examples.
    3. 3 cases differentiate
      1. already planned and assigned medication - as above (this is the patient's Baxter strips)
      2. PRN medication that has been ordered for a patient
        1. Patient-stock - patient already has the medication in a baxter strip or at home - This is the same as above (the only difference is transport) - nurse registers the medicationAdministration.
        2. No patient stock - OUT OF SCOPE for now
      3. Unplanned administration from nurse's emergency box
        1. We should support this clinically, i.e. the nurse can still register an administration without an order.


    1. Later: Delivery and not administration (This has been discussed and is a Dispense/transport event)

What happens the next day? Administration? Statement?

Before addressing this, we should ask nurses about what is the practice.

    1. Later: consume 2 items to administer only 1.
    1. medicationAdministration
      1. identifier

 



 

Technical transport: How to get information from server to client

  1. Option 1: REST PULL
    1. Nurse app must retrieve the medication administrations planned for the treatment.
    2. Search parameters in medicationRequest , search criteria same as above:
    3. GET, https://www.hl7.org/fhir/medicationorder.html#search
       
    Possible gap: how can we search for only this nurse?
    It is not in the search criteria. So..
    1. Client filtering from getting all records from all nurses
    2. IHE search extension
    3. Core: medicationrequest.Performer would be the best (not DispenseRequest.Performer).
      IHE can add search parameters, but we will align with HL7 first.
     
    Gap: Query on date of planned administration – should be part of the search criteria.
    IHE extension or FHIR Core. Will propose and align.
     
  2. Option 2: Subscription
    Search criteria are the same above
    1. Use http://build.fhir.org/subscription.html
       
    PUSH mechanism: Messaging or email.
    For messaging, we add messageheader.
    https://www.hl7.org/fhir/messageheader.html
    1.  

Question: how to handle these transport mechanisms? Jose will ask how ITI is handling it so far.