Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »


Submitting WG/Project/Implementer Group

Justification and Objectives

Use of FHIR as the vendor API has enabled maintaining a central repository for prescriptions in Australia, whilst supporting the patient's choice of attending any pharmacy in the country to obtain supply. Integration to the new ePrescribing APIs is a key success factor in rolling out paperless prescriptions. ePrescribing changes to support paperless prescriptions impacts all vendors across acute, primary and residential aged care. It also involves patient app developers. This track aims to offer all vendors an opportunity to work together, but also an opportunity for vendors not currently familiar with FHIR or active in the FHIR community to work with other vendors who are experienced with FHIR.

 

This track will use what version of FHIR.

R4

 

Clinical input requested (if any)

Not currently. The current implementation leverages the exiting FHIR standard for Medication Request with Australian extensions/localisation


Related tracks

Potential tracks that could be related include subscriptions


Proposed Track Lead

Danielle Bancroft


Expected participants

eRx Script Exchange (prescription exchange service – Fred IT)

Kate Ebrill will be speaking to vendors at the Dec Connectathon to confirm attendance (primary, acute care vendors).  


Track Orientation

A recording of the orientation webinar will be uploaded soon.



System Roles

Describe each type of system that could participate in the track

Please include information here regarding how much advance preparation will be required if creating a client and/or server.


Role Name

  1. Prescription creator
  2. Medication statement creator
  3. Medication statement renderer
  4. Prescription dispenser
  5. Patient


Scenarios

Describe the different scenarios participating systems can engage in during the connctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Scenario Step 1 Name

Register patient for ASL

Action:

From a clinical system or patient app, submit required clinical details to register a patient for an ASL via FHIR API.

Precondition:

Patient is not already registered for ASL

Success Criteria:

Patient is successfully registered and ASL is created (medication statement)

Bonus point:

 

Scenario Step 2 Name

Create a prescription for a patient registered for ASL

Action:

From a clinical prescribing system, a prescription is created and uploaded to the prescription exchange for a patient registered for ASL and is forward to the ASL stored in MK.

Precondition:

Clinical system must be connected to a prescription exchange (eRx Script Exchange will be participating and providing a test environment)

Patient is registered for ASL

Success Criteria:

Prescription is successfully added to the patient’s ASL (medication Statement)

Bonus point:

 

Scenario Step 3 Name

Patient uses patient app to view their ASL, select a prescription to have dispensed at a pharmacy

Action:

From a patient app, the patient selects to view their ASL (medication statement), selects item/s they wish to have dispensed (displays token/QR for script)

Precondition:

Patient must be registered for ASL from their patient APP

Success Criteria:

Patient’s ASL (medication statement) is successfully retrieved and displayed in the patient app.

Bonus point:

Ability to view QR token of the prescription item

 

Scenario Step 4 Name

Review patient ASL and dispense medications

Action:

From a clinical dispensing system review the patient’s ASL, select items to be dispensed and dispense scripts via the prescription exchange

Precondition:

Dispense system must be connected to a prescription exchange (eRx Script Exchange will be participating and providing a test environment)

Patient is registered for ASL

Success Criteria:

Dispenser successfully requests access to view patient’s ASL, selects an item from the rendered list (medication statement) and downloads prescription for dispensing from the exchange

Bonus point:


Scenario Step 5 Name

Mark prescription as dispensed and upload active repeat to ASL

Action:

From a clinical dispensing system, upload a record of dispense for retrieved prescription and upload a new repeat prescription to the prescription exchange for a patient registered for ASL.

Precondition:

Dispense system must be connected to a prescription exchange (eRx Script Exchange will be participating and providing a test environment)

Patient is registered for ASL

Success Criteria:

Downloaded/dispensed prescription is marked as dispensed, removed from the patient’s ASL and new repeat prescription is successfully added to the patient’s ASL (medication Statement)

Bonus point:


TestScript(s)

Indicate any test scripts that will be used to help verify system behaviour

TBD


Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

Will remove security requirements for the purpose of the connectathon


Actual Participants

Danielle Bancroft (Fred IT Group) - Australia

Paul Barry (eRx Script Exchange) - Australia

Greg Pryde (RxOne) - New Zealand

Alberto Isidro (Cerner) - Australia

Ryan Davis (GuildLink) - Australia

William Durnford (Best Practice) - Australia

Craig Schnuriger (MedAdvisor) - Australia

Anjani Jaswal (Fred IT Group) - Australia

Manjeet Singh (eRx Script Exchange) - Australia

Joaan Vargheese (Fred IT Group) - Australia

Sarwar Erfan (Modeus) - Australia

Weyn Ong (MedAdvisor) - Australia

Brian Postlethwaite (Telstra Health ) - Australia

Marc Belej (All Scripts) - Australia

Andy Robb (InterSystems) - Australia


Track Results

  • Missing drug codes in Medication Request (added to support both AMT and PBS+MF)
  • Use case for queue mgmt software to access MySL - Authentication needs investigation as cannot use site PKI
  • Patient match operation needs review
  • Need to ensure patient validation exist to avoid more than one patient being addedr
  • Request consent for org has error in the xml example
  • Profiles need to be reviewed with regard to minimum mandatory fields etc
  • Request consent for org has error in the xml example


Identified certain workflow scenarios requiring further work in next phase:

  • Edit patient call
  • Carer mode access
  • Identifier for patient app to use (cannot/don't have IHI)
  • Flag med in request as hidden
  • Mapping of pharmacy site IDs from third party apps against PDS site IDs





  • No labels