Difference between revisions of "FHIR Resources for MMM"

From IHE Wiki
Jump to navigation Jump to search
m
 
(6 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
== Functional resources – transaction content ==
 
== Functional resources – transaction content ==
# Get medications for a patient: medicationRequest  http://build.fhir.org/medicationrequest.html  
+
 
 +
Step 1: asking the server for relevant medication requests
 +
 
 +
# Search medications for a patient: medicationRequest  http://build.fhir.org/medicationrequest.html  
 
## Must have a specific parameter (medicationRequest.intent or other) to select only the lists of administrations planned, not the prescriptions and encoded orders, etc.
 
## Must have a specific parameter (medicationRequest.intent or other) to select only the lists of administrations planned, not the prescriptions and encoded orders, etc.
 
## Search criteria:  
 
## Search criteria:  
### Date of administration
+
### '''OPEN:''' Date/time of administration=<...> <-- this should be in dosageInstruction.???
### Patient
+
### Patient=<...>
### Nurse
+
### Status = Active
# Send report of administration: medicationAdministration http://build.fhir.org/medicationadministration.html  
+
### '''OPEN:''' Nurse=<...>
 +
### medicationRequest.intent="instance-order" '''<-- RESOLVED
 +
#### 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
 +
## The response is several MedicationRequest resources:
 +
### Identifier = XXX
 +
### Definition (if there is a protocol, but not now)
 +
### BasedOn: Pointer to prescription/plan
 +
### Requisition: the multiline prescription to which each prescription belongs
 +
### Status = active
 +
### Stage: “instance-order”
 +
### Medication: each medication
 +
### Patient: patient resource
 +
### Context: encounter / ????
 +
### SupportingInformation (none?)
 +
### dateWritten: when it was decoded
 +
### Requester:
 +
### reasonCode: the indication or diagnosis
 +
### reasonReference: a pointer to a condition or observation
 +
### note: administration notes
 +
### category: outpatient or inpatient
 +
### dosageinstruction.
 +
#### Sequence=?
 +
#### Text=??? (we must clarify how this differs from the Notes above)
 +
#### additionalInstructions=?
 +
#### Timing
 +
##### event = 13:00 or
 +
##### When = lunch
 +
#### Site
 +
#### Route
 +
#### Method
 +
#### Dose.doseQuantity=1
 +
#### 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
 +
 
 +
# 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.
''' '''
+
 
 +
## medicationAdministration
 +
### identifier
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 
== 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
Line 20: Line 99:
 
## Search parameters in medicationRequest , search criteria same as above:
 
## Search parameters in medicationRequest , search criteria same as above:
 
## GET, https://www.hl7.org/fhir/medicationorder.html#search
 
## GET, https://www.hl7.org/fhir/medicationorder.html#search
#: ''' '''
+
##: 
 
#: Possible gap: '''how can we search for only this nurse?'''  
 
#: Possible gap: '''how can we search for only this nurse?'''  
 
#: It is not in the search criteria. So..
 
#: It is not in the search criteria. So..
Line 26: Line 105:
 
## IHE search extension
 
## IHE search extension
 
## Core: medicationrequest.Performer would be the best (not DispenseRequest.Performer).
 
## Core: medicationrequest.Performer would be the best (not DispenseRequest.Performer).
#:: IHE can add search parameters, but we will align with HL7 first.
+
##:: 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.'''  
 
#: Gap: '''Query on date of planned administration – should be part of the search criteria.'''  
 
#: IHE extension or FHIR Core. Will propose and align.
 
#: IHE extension or FHIR Core. Will propose and align.
#: ''' '''
+
#: 
 
# Option 2: Subscription
 
# Option 2: Subscription
 
#: Search criteria are the same above
 
#: Search criteria are the same above
#: Use http://build.fhir.org/subscription.html  
+
## Use http://build.fhir.org/subscription.html  
''' '''
+
##: 
PUSH mechanism: Messaging or email.  
+
#: PUSH mechanism: Messaging or email.  
For messaging, we add messageheader.
+
#: For messaging, we add messageheader.
https://www.hl7.org/fhir/messageheader.html
+
#: https://www.hl7.org/fhir/messageheader.html
''' '''
+
##: 
 +
 
 
Question: how to handle these transport mechanisms? Jose will ask how ITI is handling it so far.
 
Question: how to handle these transport mechanisms? Jose will ask how ITI is handling it so far.

Latest revision as of 06: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.