FHIR Chat · ePrescribring track (con23) · connectathon mgmt

Stream: connectathon mgmt

Topic: ePrescribring track (con23)

Alberto Isidro (Feb 01 2020 at 22:30):

.

Paul Barry (Feb 01 2020 at 22:33):

ok Paul from Fred here who can hear us and give us the following:
Vendor Name
Clinical System or Patient App integration (or both)

Alberto Isidro (Feb 01 2020 at 22:34):

Alberto Isidro
Cerner (EMR)

Greg Pryde (Feb 01 2020 at 22:34):

Greg Pryde , from RxOne, Australia and New Zealand ePrescribing. Pharmacy system RxOne

Andy Robb (Feb 01 2020 at 22:35):

Hey Andy @InterSystems here

Manjeet Singh (Feb 01 2020 at 22:41):

Manjeet - Fred - ePrescribing

Sarwar Erfan (Feb 01 2020 at 22:42):

Sarwar from Modeus - Patient App integration

Craig Schnuriger (Feb 01 2020 at 22:43):

Craig from MedAdvisor

Paul Barry (Feb 01 2020 at 22:44):

If you haven't found it already the IG is here
https://mvf-sha-npd-iguide-web-au-se.azurewebsites.net/mysl/dev/index.html
Please review the IG first and if you have any questions come and grab me or chat here

Joaan Vargheese (Feb 01 2020 at 22:45):

(deleted)

Paul Barry (Feb 01 2020 at 22:46):

@Paul Barry @Manjeet Singh @Brian Postlethwaite @Danielle Bancroft are here from Fred to answer any questions and assist

Joaan Vargheese (Feb 01 2020 at 22:47):

Joaan - Fred Dispense - ePrescribing

Paul Barry (Feb 01 2020 at 22:48):

Alberto Isidro
Cerner (EMR)

here is the patient search link
{{FHIR_Base_URL}}/Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&_revinclude=Consent:patient

Sarwar Erfan (Feb 01 2020 at 22:48):

If you haven't found it already the IG is here
https://mvf-sha-npd-iguide-web-au-se.azurewebsites.net/mysl/dev/index.html
Please review the IG first and if you have any questions come and grab me or chat here

It requires login

Paul Barry (Feb 01 2020 at 22:50):

If you haven't found it already the IG is here
https://mvf-sha-npd-iguide-web-au-se.azurewebsites.net/mysl/dev/index.html
Please review the IG first and if you have any questions come and grab me or chat here

It requires login

working on opening it up connectathon now

Paul Barry (Feb 01 2020 at 22:54):

Lets try that again. The public IG is
https://mysl-hl7-sydney.azurewebsites.net/fhir/ig

Ryan Davis (Feb 01 2020 at 22:57):

Ryan Davis - GuildLink :cowboy:

Marc Belej (Feb 01 2020 at 22:58):

Lets try that again. The public IG is
https://mysl-hl7-sydney.azurewebsites.net/fhir/ig

Not giving me what's expected I think

pasted image

Manjeet Singh (Feb 01 2020 at 23:00):

https://mysl-hl7-sydney.azurewebsites.net/ig/

Try this please.

Weyn Ong (Feb 01 2020 at 23:18):

Weyn from MedAdvisor

Paul Barry (Feb 01 2020 at 23:38):

Lets try that again. The public IG is
https://mysl-hl7-sydney.azurewebsites.net/fhir/ig

Not giving me what's expected I think

pasted image

https://mysl-hl7-sydney.azurewebsites.net/ig/

Paul Barry (Feb 01 2020 at 23:45):

How are we all going? Anyone managed to get an SMS out yet?

Paul Barry (Feb 01 2020 at 23:47):

Who going to be first to complete the Assisted Registration workflow?

pasted image

Brian Postlethwaite (Feb 02 2020 at 00:13):

@Danielle Bancroft, Should the MedicationRequest include the number of repeats/quantity remaining on the script?
(@Lloyd McKenzie asked)
And while we're at it, what about the validity period?

Danielle Bancroft (Feb 02 2020 at 00:17):

Yes, from memory it's number of repeats authorised/number supplied, so if an original would be say 5/0 as no supply. Validity is 12mths from prescribed date, we don't explicitly state expiry as PES will auto-expire at 12 months, dispense also manages this but the fringe scripts like Controlled Drug are 6mth and also handled by dispense

Paul Barry (Feb 02 2020 at 00:38):

Someone was looking for an example MedicationRequest with AMT codes.
{{FHIR_Base_URL}}/MedicationRequest/4e23d8f8bea44360bd9ba4a6917924c5

Sarwar Erfan (Feb 02 2020 at 00:43):

I have created an Organization, a Patient and a Consent (with status = proposed). Should I be expecting an SMS at this point or just do another PUT /Consent to set status = active?

Manjeet Singh (Feb 02 2020 at 00:46):

yes, you should get SMS to respond for the consent

Paul Barry (Feb 02 2020 at 00:58):

I have created an Organization, a Patient and a Consent (with status = proposed). Should I be expecting an SMS at this point or just do another PUT /Consent to set status = active?

@Sarwar Erfan when the patient replies to the SMS, the MySL system will set the Consent status to "active"

Paul Barry (Feb 02 2020 at 00:58):

I have created an Organization, a Patient and a Consent (with status = proposed). Should I be expecting an SMS at this point or just do another PUT /Consent to set status = active?

Sarwar Erfan when the patient replies to the SMS, the MySL system will set the Consent status to "active"

If the patient replies with a 1 or 2 that is

Paul Barry (Feb 02 2020 at 01:09):

Great progress everyone - a number of vendors are completing registrations and receiving SMS already and the questions are flying thick and fast. Once a patient is registered the permission to access the patient's MySL is dictated by the existence of a consent resource authored by that site. Once the security model is implemented (it isn't yet), the api will only return consent resources authored by that site only for that patient. i.e. if a patient is returned and your site has access only one consent resource (your one) will be returned in the response. If there is a patient record but no consent resource, that means the patient has a MySL but your site does not have permission yet so you need to request it by posting a consent resource to the server. This sequence is described below. Shout out if you have any questions

pasted image

Paul Barry (Feb 02 2020 at 01:21):

Just noticed ".id" in the diagrams is not supported so please use omit it and use
{{FHIR_Base_URL}}/MedicationRequest?patient=2fc57699576f4106bc211ad237f4c8dd

Sarwar Erfan (Feb 02 2020 at 01:28):

Thanks for the help @Manjeet Singh and @Paul Barry .
Two things:

1. The diagram indicates the SMS will be sent after POST /VerificationResult. But I got the SMS immediately after POST /Consent

2. GET /MedicationRequest is obviously empty for a new patient. Is there a way to add something by myself for testing?

Manjeet Singh (Feb 02 2020 at 01:32):

Thanks for the help Manjeet Singh and Paul Barry .
Two things:

1. The diagram indicates the SMS will be sent after POST /VerificationResult. But I got the SMS immediately after POST /Consent

2. GET /MedicationRequest is obviously empty for a new patient. Is there a way to add something by myself for testing?

1. Yes, we have not implemented the 'VerificationResult' as part of this POC. So once the Consent POST is done, you will receive the SMS.
2. you can add MedicationRequest yourself as well.
   See below the test payload

{
"resourceType": "MedicationRequest",
"id": "d5f44a8ad9f640c3a5c2931ed9c8e766",
"meta": {
"profile": [
"http://fhir.fred.com.au/my-sl/StructureDefinition/mysl-medicationrequest"
]
},
"identifier": [
{
"use": "official",
"type": {
"coding": [
{
"system": "http://hl7.org.au/fhir/v2/0203",
"code": "ETP",
"display": "ETP Identifier"
}
]
},
"system": "http://fhir.erx.com.au/NamingSystem/identifiers#scid",
"value": "19WC94RKWRX54QX1D4",
"assigner": {
"display": "eRX"
}
}
],
"status": "active",
"intent": "order",
"medicationCodeableConcept": {
"text": "Imuran 1mg"
},
"subject": {
"reference": "Patient/23734d429d134730b581d6f0e9fce9d2",
"display": "Brian Jonas"
},
"authoredOn": "2020-01-01",
"requester": {
"display": "Dr Maek Meebetta"
},
"dosageInstruction": [
{
"sequence": 1,
"text": "Take one tablet daily as directed"
}
]
}

Brian Postlethwaite (Feb 02 2020 at 01:47):

Yes, the SMS happens after the consent request... The verificationresult is an independant action, so didn't want to tie it to that.
Also, down the track when a new pharmacy/org wants to have access, all they do is create the Consent request, no need for any of the other actions there.

Paul Barry (Feb 02 2020 at 02:56):

We found (it was @Greg Pryde of course) a bug on the fhir server where searching by multiple identifiers (Get me a patient with this IHI or this Medicare Number) where the name space is included was not working e.g.

{{FHIR_Base_URL}}/Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|1234567890123456,http://ns.electronichealth.net.au/id/medicare-number|2806546876

However if you omit the system name space and just provide the system value the search will work. So please use

{{FHIR_Base_URL}}/Patient?identifier=1234567890123456,2806546876

Brian Postlethwaite (Feb 02 2020 at 03:06):

(This is a (recently) known bug in the server - and its nasty after looking into it)

Paul Barry (Feb 02 2020 at 03:56):

Ok a lot of patient app developers here today which is great but sets us up for some slightly different interactions with the MySL. A patient app registration is different because we are relying on the existing app registration and verification process to identify the patient. The security model will be interesting but the interactions with FHIR are simpler - first lets focus on the latter. Lets start with a patient registering for the MySL via their patient app. The sequence is described below. Let me know what you think.

pasted image

Sarwar Erfan (Feb 02 2020 at 04:26):

Ok a lot of patient app developers here today which is great but sets us up for some slightly different interactions with the MySL. A patient app registration is different because we are relying on the existing app registration and verification process to identify the patient. The security model will be interesting but the interactions with FHIR are simpler - first lets focus on the latter. Lets start with a patient registering for the MySL via their patient app. The sequence is described below. Let me know what you think.

pasted image

This flow makes things easier for a Patient app. But it is missing the Consent step, which is a must from a patient’s point of view.

The patient app perhaps should not make the POST /Patient call to create a new Patient. It can be reserved for Clinical systems (Prescribing / Dispense)

If there is no Patient record (i.e. No ASL) for a person, they should either visit a GP/Pharmacist to create the Patient entity (e.g. create ASL) or do it self service via MyHealthRecord.

Then, the patient App publisher will become an organization in MySL and the Patient App can create a “proposed” Consent to give access to that app for a specific time.

patient_app.png

Paul Barry (Feb 02 2020 at 04:33):

Ok a lot of patient app developers here today which is great but sets us up for some slightly different interactions with the MySL. A patient app registration is different because we are relying on the existing app registration and verification process to identify the patient. The security model will be interesting but the interactions with FHIR are simpler - first lets focus on the latter. Lets start with a patient registering for the MySL via their patient app. The sequence is described below. Let me know what you think.

pasted image

This flow makes things easier for a Patient app. But it is missing the Consent step, which is a must from a patient’s point of view.

The patient app perhaps should not make the POST /Patient call to create a new Patient. It can be reserved for Clinical systems (Prescribing / Dispense)

If there is no Patient record (i.e. No ASL) for a person, they should either visit a GP/Pharmacist to create the Patient entity (e.g. create ASL) or do it self service via MyHealthRecord.

Then, the patient App publisher will become an organization in MySL and the Patient App can create a “proposed” Consent to give access to that app for a specific time.

patient_app.png

@Sarwar Erfan if the patient is verified, authenticated and requesting to view their own MySL (or create one) why do you believe a consent request is required?

Sarwar Erfan (Feb 02 2020 at 05:23):

Sarwar Erfan if the patient is verified, authenticated and requesting to view their own MySL (or create one) why do you believe a consent request is required?

@Paul Barry :
Not from a technical point of view, but from the privacy point of view giving blanket access will make the users nervous.

Just like every pharmacy need to get separate consent - the user is assured, if they have not replied to the SMS to give consent to a specific pharmacy or GP clinic, they cant access their script list.
It should be the same for Patient Apps. When the user gives consent to Patient App X for 1 day, they should be assured Patient App Y is not also getting the ability to query (because the user does not trust the publisher of App Y?) and also Patient App X can no longer access the script list after 1 day due to some bug in the system which keeps syncing indefinitely :)

When the user wants to view the script list in Patient App X, they get the SMS : "Do you authorise Patient App X to access the MyScript List..."

Also, users need a way to revoke access to any Patient App, with separate Consent, those can be deleted to revoke access.

Having individual Consent will increase user confidence in the Patient App concept.

Sarwar Erfan (Feb 02 2020 at 05:31):

Someone was looking for an example MedicationRequest with AMT codes.
{{FHIR_Base_URL}}/MedicationRequest/4e23d8f8bea44360bd9ba4a6917924c5

In this sample, MP is used (31865003). MPUU instead of MP (or TPUU if the doctor has prescribed a specific brand) would be more helpful if including AMT information.

Brian Postlethwaite (Feb 02 2020 at 05:32):

Ah, I see the difference, its the consent by the Patient to the Patient App. Have I got that right @Sarwar Erfan ?

Sarwar Erfan (Feb 02 2020 at 05:32):

Ah, I see the difference, its the consent by the Patient to the Patient App. Have I got that right Sarwar Erfan ?

Right, where the Patient App is simply an Organization entity, no change required in any existing concept.

Manjeet Singh (Feb 02 2020 at 05:52):

@Sarwar Erfan I got your point of view and it need discussion to come to some conclusion.

Sarwar Erfan (Feb 02 2020 at 09:40):

Sarwar Erfan I got your point of view and it need discussion to come to some conclusion.

Yup, I believe there will be discussions on this topic among the stakeholders in the coming months and some standard workflows will be defined.
Not expecting any decision from this Connectahon, but it was very helpful to be able to get different perspectives.

Sarwar Erfan (Feb 02 2020 at 22:13):

Good morning everyone :) Had a very fruitful first day, thanks to everyone who helped.

My main goals for today:

1. Get to know the MedicationRequest more
   a. Most fields have cardinality 0..1, so better we know which fields can we expect to be present there (e.g. it will be sweet to have dispenseRequest, dosageInstruction though they have 0..1 cardinality)
   b. Get the most information out of MedicationRequest without querying eRx/MediSecure
   c. Optionally: What is the minimum set of information that the Script exchanges (eRX/MediSecure) need to send when creating the MedicationRequest for the original/repeat

2. Onboarding : What will be the process for an organization which does not have eRx/MediSecure access to get access to the MySL - just some heads up (seems NASH cert will be required for JWT?)

Andy Robb (Feb 02 2020 at 22:35):

We've got a Medication Request on the ASL for patient id 008f5be275e645fcb5eb4e649c8a7d77 (Amanda Holding) - this is ready to be dispensed if any system is ready to pick this up...thx

Alberto Isidro (Feb 02 2020 at 22:37):

If the clinical software needs to upload a prescription, but does not need to see the ASL, do we still need to go through the patient consent and verification result steps?
Is there any diagram that represent this worflow?
Do we chave to check if a patient has an ASL, and if it does always post the prescription?
Would we be creating an ASL at some point or do we require the patient to have one before created by a patient app or a web portal?

Brian Postlethwaite (Feb 02 2020 at 22:40):

The Consent is only required for the clinical software to be able to see the patient's medications.
Prescriptions are loaded into the ASL through the script exchange, but only if the patient has an active record, so the prescribing software doesn't actually need to specifically do anything :slight_smile:

Paul Barry (Feb 02 2020 at 23:14):

Good morning everyone :) Had a very fruitful first day, thanks to everyone who helped.

My main goals for today:

1. Get to know the MedicationRequest more
   a. Most fields have cardinality 0..1, so better we know which fields can we expect to be present there (e.g. it will be sweet to have dispenseRequest, dosageInstruction though they have 0..1 cardinality)
   b. Get the most information out of MedicationRequest without querying eRx/MediSecure
   c. Optionally: What is the minimum set of information that the Script exchanges (eRX/MediSecure) need to send when creating the MedicationRequest for the original/repeat

2. Onboarding : What will be the process for an organization which does not have eRx/MediSecure access to get access to the MySL - just some heads up (seems NASH cert will be required for JWT?)

Thanks Sarwar
Great to hear you making good progress! One thing to remember with ePrescribing, is that the URI (token based approach) or a script with an Active Script List are just "pointers" to the legal prescription held within a Prescription Exchange (eRx or MediSecure) or Direct Prescription Delivery Service (DPDS) that is certified for ePrescribing - DPDS tend to exist in hospital scenarios. The main point I'm making here is that both the URI or a script presented in the MySL only gives you enough information to identify it (from another script), direct it to pharmacy queue, manage it through a pharmacy workflow queue etc. To dispense the script you must use the SCID or barcode to pull it down from a PES (or DPDS) - at that point you will receive the full information and only via a certified PES or DPDS may that prescription be dispensed. The electronic script can also only be dispensed using an ePrescribing conformant pharmacy system (connected to a PES or DPDS). So in response to your questions.

1a - Have a look at the MedicationRequest profile on the IG for what is required but as the data is coming from 40 plus different vendors via eRx and MediSecure PES, it may not always be present and we have limited control over that. A dispenseRequest will never be present in the MySL because we only care about Active scripts that have not yet been dispensed. A repeat will result in a brand new MedicationRequest

1b - As above you should always be using the MySL in conjunction with eRx or MediSecure to organise and get your scripts dispensed in the manner I've described above. The MySL is not a patient's meds history used for clinical decision - it is a patient's list of current 'active' scripts.

1c - The PES do not validate the payload as it is encrypted at source, however the resulting MedicationRequest sent to the MySL, will be validated in accordance with the profile. The profile for the MR is our first cut, there may be some tweaking to come

2c - The ASL conformance points for both dispensing and prescribing systems is that they use their existing PES security model to access the MySL - so for now we'll be using Medicare certs for eRx sites, MediSecure self-signed certs for MediSecure site. In the future we'll move to NASH as the Medicare certs are deprecated. As Medicare and NASH use the same CA, this could be a simple as certificate upgrade. The PES will drive this. For patient apps, we'll work with each vendor to leverage there existing security model using an OAuth approach combined with a client level trusted. The security model will be published soon. Each vendor consuming the MySL, will be subject to an onboarding and certification process conducted by Fred/MediSecure

Sarwar Erfan (Feb 02 2020 at 23:22):

Good morning everyone :) Had a very fruitful first day, thanks to everyone who helped.

My main goals for today:

1. Get to know the MedicationRequest more
   a. Most fields have cardinality 0..1, so better we know which fields can we expect to be present there (e.g. it will be sweet to have dispenseRequest, dosageInstruction though they have 0..1 cardinality)
   b. Get the most information out of MedicationRequest without querying eRx/MediSecure
   c. Optionally: What is the minimum set of information that the Script exchanges (eRX/MediSecure) need to send when creating the MedicationRequest for the original/repeat

2. Onboarding : What will be the process for an organization which does not have eRx/MediSecure access to get access to the MySL - just some heads up (seems NASH cert will be required for JWT?)

Thanks Sarwar
Great to hear you making good progress! One thing to remember with ePrescribing, is that the URI (token based approach) or a script with an Active Script List are just "pointers" to the legal prescription held within a Prescription Exchange (eRx or MediSecure) or Direct Prescription Delivery Service (DPDS) that is certified for ePrescribing - DPDS tend to exist in hospital scenarios. The main point I'm making here is that both the URI or a script presented in the MySL only gives you enough information to identify it (from another script), direct it to pharmacy queue, manage it through a pharmacy workflow queue etc. To dispense the script you must use the SCID or barcode to pull it down from a PES (or DPDS) - at that point you will receive the full information and only via a certified PES or DPDS may that prescription be dispensed. The electronic script can also only be dispensed using an ePrescribing conformant pharmacy system (connected to a PES or DPDS). So in response to your questions.

1a - Have a look at the MedicationRequest profile on the IG for what is required but as the data is coming from 40 plus different vendors via eRx and MediSecure PES, it may not always be present and we have limited control over that. A dispenseRequest will never be present in the MySL because we only care about Active scripts that have not yet been dispensed. A repeat will result in a brand new MedicationRequest

1b - As above you should always be using the MySL in conjunction with eRx or MediSecure to organise and get your scripts dispensed in the manner I've described above. The MySL is not a patient's meds history used for clinical decision - it is a patient's list of current 'active' scripts.

1c - The PES do not validate the payload as it is encrypted at source, however the resulting MedicationRequest sent to the MySL, will be validated in accordance with the profile. The profile for the MR is our first cut, there may be some tweaking to come

2c - The ASL conformance points for both dispensing and prescribing systems is that they use their existing PES security model to access the MySL - so for now we'll be using Medicare certs for eRx sites, MediSecure self-signed certs for MediSecure site. In the future we'll move to NASH as the Medicare certs are deprecated. As Medicare and NASH use the same CA, this could be a simple as certificate upgrade. The PES will drive this. For patient apps, we'll work with each vendor to leverage there existing security model using an OAuth approach combined with a client level trusted. The security model will be published soon. Each vendor consuming the MySL, will be subject to an onboarding and certification process conducted by Fred/MediSecure

@Paul Barry : You answered everything to the point, thanks heaps :thank_you:

Paul Barry (Feb 02 2020 at 23:28):

Important distinction:

"The Solution Architecture and Conformance Profile refer to a token-based ‘open’ delivery model for consumer choice of supply. The Agency and TWG are currently finalising an additional architectural model referred to as an Active Script List (ASL) where consumers can access a list of their active prescriptions at a pharmacy without the need to have a token."

https://www.digitalhealth.gov.au/implementation-resources/ehealth-foundations/electronic-prescribing

The "MySL" is Fred and MediSecure's implementation of the "ASL" architectural model

Sarwar Erfan (Feb 02 2020 at 23:29):

My understanding was that the [base]/MedicationRequest would only return the MedicationRequests with status = active. But it is also returning the completed ones (example: [base]/MedicationRequest?patient=008f5be275e645fcb5eb4e649c8a7d77&_format=json)

MR_status_active.png

MR_status_completed.png

Paul Barry (Feb 02 2020 at 23:34):

My understanding was that the [base]/MedicationRequest would only return the MedicationRequests with status = active. But it is also returning the completed ones (example: [base]/MedicationRequest?patient=008f5be275e645fcb5eb4e649c8a7d77&_format=json)

MR_status_active.png

MR_status_completed.png

Your understanding is correct. Once the MySL is fully connected to both eRx and MediSecure the dispensed script will be removed once dispensed (via a PES) This has not been developed yet for the connectathon.

Paul Barry (Feb 02 2020 at 23:37):

An ASL can contain both classic paper based or electronic (ETP2) active prescriptions - they are just pointers to the active prescriptions held in a PES. However when it comes to dispensing them, the pharmacy system still need to integrate with the PES to pull down the script - if the script is the classic paper based script, they will still request the paper prescription from the patient, carer in order to complete the dispense
The MySL is a convenient way to merge the old with the new and keep all active scripts in one place so they can be managed via the pharmacy queue. We expect the uptake of electronic queues to be very popular now with the introduction of ePrescribing.

Sarwar Erfan (Feb 02 2020 at 23:43):

My understanding was that the [base]/MedicationRequest would only return the MedicationRequests with status = active. But it is also returning the completed ones (example: [base]/MedicationRequest?patient=008f5be275e645fcb5eb4e649c8a7d77&_format=json)

MR_status_active.png

MR_status_completed.png

Your understanding is correct. Once the MySL is fully connected to both eRx and MediSecure the dispensed script will be removed once dispensed (via a PES) This has not been developed yet for the connectathon.

Great.. I think I am getting the hang of it... Th ASL is a snapshot, it does not apply business rules. It is the responsibility of the prescribing/dispensing/other systems to maintain it. The system that dispenses one of the active scripts may remove it and add a new one (if there are any more repeats left).

Then it will be similar for expired ones, as the expiry date may vary from state to state due to the S4D/S11/S8 list is not being federal.
Who will remove expired scripts with repeats left can be an interesting question if the patient never presents that token to a pharmacy after the expiry :thinking:

Paul Barry (Feb 03 2020 at 00:05):

My understanding was that the [base]/MedicationRequest would only return the MedicationRequests with status = active. But it is also returning the completed ones (example: [base]/MedicationRequest?patient=008f5be275e645fcb5eb4e649c8a7d77&_format=json)

MR_status_active.png

MR_status_completed.png

Your understanding is correct. Once the MySL is fully connected to both eRx and MediSecure the dispensed script will be removed once dispensed (via a PES) This has not been developed yet for the connectathon.

Great.. I think I am getting the hang of it... Th ASL is a snapshot, it does not apply business rules. It is the responsibility of the prescribing/dispensing/other systems to maintain it. The system that dispenses one of the active scripts may remove it and add a new one (if there are any more repeats left).

Then it will be similar for expired ones, as the expiry date may vary from state to state due to the S4D/S11/S8 list is not being federal.
Who will remove expired scripts with repeats left can be an interesting question if the patient never presents that token to a pharmacy after the expiry :thinking:

These are great questions @Sarwar Erfan - I can see you are really thinking this all through from many different aspects.
With regards to MedicationRequests, a system connected to the MySL will never add, remove, update or delete them. They are effectively a read-only representation of an active script put there by eRx or MediSecure so any updates are pushed to the MySL from one of the PES. Those creates, updates or deletes are managed by the clinical or dispensing system via the two PES (eRx/MediSecure) and the changes are reflected downstream in the MySL. The expiration validation rules are managed by the PES - once the PES believes a script is expired you cant dispense it so even though its still in the MySL its effectively useless. (The MySL will likely have a "clean-up" utility that removes expired scripts that were never dispensed via the PES and therefore never removed from the MySL)

Paul Barry (Feb 03 2020 at 00:14):

Ok we have set up connection to eRx that will push MedicationRequests to a patient's MySL. Does anyone have a test patient they are using that I could send some script to there MySL. You can then test they are getting attached correctly and returned in your list? Please provide the IHI of your test patient

Ryan Davis (Feb 03 2020 at 00:16):

8003608188890512 :working_on_it:

Craig Schnuriger (Feb 03 2020 at 00:18):

8003608188890512

Ryan Davis (Feb 03 2020 at 00:28):

i have moved to a new, better, IHI 8001608199990516

Ryan Davis (Feb 03 2020 at 00:28):

lower is better right?

Brian Postlethwaite (Feb 03 2020 at 00:34):

I'm pondering how an IHI can be better than another one...

Sarwar Erfan (Feb 03 2020 at 00:40):

Thanks again @Paul Barry . Regarding the expired ones, a clean-up utility will be required. But it will be interesting due to different legislations, e.g. S4D's are 12 months in VIC but 6 months in TAS (and NSW as well).
The reason I brought up expiry is, though those cannot (and will not) be dispensed, showing it on the same list may (in fact from my experience, it will happen) lead to arguments between the patient and the pharmacist. From the patient's view, "I see it in the list, if you are not going to dispense it, why it is on my app?"
This also happens now when the patient leaves the paper script at the pharmacy (on file) and visits the pharmacy after it expired - "I left the script with you, why won't you dispense? Why didn't you call me to inform it is expiring?"
With the patient apps, we try to minimize these situations with repeat and expiry reminders via push/sms

Paul Barry (Feb 03 2020 at 00:42):

i have moved to a new, better, IHI 8001608199990516

A better IHI is one that exists ;-) - did you register this one @Ryan Davis I cant find them
https://mysl-hl7-sydney.azurewebsites.net/fhir/Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8001608199990516&_revinclude=Consent:patient

Sarwar Erfan (Feb 03 2020 at 00:44):

Ok we have set up connection to eRx that will push MedicationRequests to a patient's MySL. Does anyone have a test patient they are using that I could send some script to there MySL. You can then test they are getting attached correctly and returned in your list? Please provide the IHI of your test patient

If possible, this patient:
IHI: ihibugsbunny
Patient ID: eab72fc63c1947c5b8c43d7e6fc8b927

For testing, did not use a numeric IHI, please bear with it :)

Ryan Davis (Feb 03 2020 at 00:55):

@Paul Barry you're probably hitting the bug from earlier where you can't include the namespace in an identifier search, but I'm also ready to believe I did something wrong

Ryan Davis (Feb 03 2020 at 00:56):

the patient id is fe2927d4a7834723b1b37db6f23ab4b8

Paul Barry (Feb 03 2020 at 00:59):

8003608188890512

Ok @Craig Schnuriger you should see a couple of MedicationRequests going via eRx appearing in your MySL?

Craig Schnuriger (Feb 03 2020 at 01:00):

thanks checking it out now

Craig Schnuriger (Feb 03 2020 at 01:06):

looking good, I'm getting the data, rendering it out now

Jesus Nunez (Feb 03 2020 at 01:12):

Screen-Shot-2020-02-03-at-12.10.32-pm.png

Jesus Nunez (Feb 03 2020 at 01:12):

Web page sample for creating a MedicationRequest

Sarwar Erfan (Feb 03 2020 at 01:17):

My little iOS app with my test patient:

• View basic demographics
• View Consents (all states)
• View Scripts
• Render the QR to present to the Pharmacist
  Simulator-Screen-Shot-iPhone-8-Plus-2020-02-03-at-12.14.44.png Simulator-Screen-Shot-iPhone-8-Plus-2020-02-03-at-12.14.46.png Simulator-Screen-Shot-iPhone-8-Plus-2020-02-03-at-12.14.48.png
  
  
  

Simulator-Screen-Shot-iPhone-8-Plus-2020-02-03-at-12.17.46.png

Paul Barry (Feb 03 2020 at 01:17):

Paul Barry you're probably hitting the bug from earlier where you can't include the namespace in an identifier search, but I'm also ready to believe I did something wrong

you put an extra forward slash on the IHI namespace. let me know when you have updated the patient and I'll send some script through

Ryan Davis (Feb 03 2020 at 01:22):

@Paul Barry have removed the slash and moved to 8001508199990516 which I think may be the best IHI i've come up with yet

Craig Schnuriger (Feb 03 2020 at 01:24):

Scripts coming across from eRx

pasted image

Paul Barry (Feb 03 2020 at 02:32):

Paul Barry have removed the slash and moved to 8001508199990516 which I think may be the best IHI i've come up with yet

Fire in the hole! Scripts coming your way!

Ryan Davis (Feb 03 2020 at 02:42):

Thanks :tada:

Ryan Davis (Feb 03 2020 at 02:44):

we will be requiring our patients to download LINQPad to access their ASL :working_on_it:
pasted image

Ryan Davis (Feb 03 2020 at 02:45):

for people who don't know barcodes what's the barcode system i really want

Brian Postlethwaite (Feb 03 2020 at 03:11):

That's a nice screenshot for the report out - @Danielle Bancroft :rofl:

Ryan Davis (Feb 03 2020 at 03:14):

i've been informed the technical term is "QR Code" so we are now basically ship ready
pasted image

Brian Carter (Apr 20 2020 at 03:52):

I have a question about the consent resource.
I refer to Paul Barry's Sequence Diagrams – Site with Consent.

image.png

Using the call - Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&_revinclude=Consent:patient
The note on the diagram says: “We make one call and use a _revinclude flag to check consent at the same time. In this instance the patient has a MySL and the site already has consent”.

The implication is that if a Consent resource is returned, then we have access.
However, looking in the 2 Consent resources returned in the bundle, there are Organisation references in the Provision/Actor properties. These are just a references to the organisations.
How do I know if this organisation is mine?
Do I not need to get the details of the organisation/s in the Consent resource/s to check if that consent is for my organisation?
Do I need to do a separate call to the FHIR database to get each of the organisations to check if it is mine? Or is there a way I can the all of the organisations to be returned in the bundle with some sort of an _include command?
Or is there some other way to check consent for my organisation?
Thanks.

Paul Barry (Apr 20 2020 at 03:57):

Brian Carter said:

I have a question about the consent resource.
I refer to Paul Barry's Sequence Diagrams – Site with Consent.

image.png

Using the call - Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&_revinclude=Consent:patient
The note on the diagram says: “We make one call and use a _revinclude flag to check consent at the same time. In this instance the patient has a MySL and the site already has consent”.

The implication is that if a Consent resource is returned, then we have access.
However, looking in the 2 Consent resources returned in the bundle, there are Organisation references in the Provision/Actor properties. These are just a references to the organisations.
How do I know if this organisation is mine?
Do I not need to get the details of the organisation/s in the Consent resource/s to check if that consent is for my organisation?
Do I need to do a separate call to the FHIR database to get each of the organisations to check if it is mine? Or is there a way I can the all of the organisations to be returned in the bundle with some sort of an _include command?
Or is there some other way to check consent for my organisation?
Thanks.

Welcome @Brian Carter !
Currently because the security model hasn't been implemented, you are seeing all consent objects for any organisation that has consent to this patient's MySL. Once the security model has been implemented, it will only return consent resources that belong to the site making the call. i.e. the FHIR server will filter out any other consent resources and you will just see yours - if you have consent. The PKI cert attached in the call the sites makes, will be used to identify the site and therefore only return consent resource that match that site Id

John Moehrke (Apr 20 2020 at 15:05):

The fact that a REST query would return only (subset) of the results because it auto-enforces Consent is not unusual. This kind of transparent enforcement is what would be normally expected. I don't think you should require your clients include the _revinclude, in fact including this or not including this should result in the same result.

Brian Carter (Apr 23 2020 at 01:13):

A question about registering a patient.
I refer to Paul Barry's sequence diagram - MySL-Assisted-Reg

image.png

Check required MySL data.
Can someone please point me to where I can find the mandatory data requirements.

Thanks,
Brian.

Brian Carter (Apr 23 2020 at 03:51):

A question about checking for the existence of a MySL

I refer to the document "DH-3139:2020 - Electronic Prescribing - Conformance Test Specification - Prescribing Systems" issued by the ADHA.
The mandatory conformance requirement PRES-54 states:
"The system SHALL establish whether the SoC has registered for participation in an Active Script List by polling the ASL Registry Services using the SoC’s IHI number, given name and family name."

The sequence diagram – Site with Consent - indicates that the server call "Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&_revinclude=Consent:patient" is required.

My question is how does this fulfill the conformance requirement PRES-54? Does this not also require the patient's name to be included in the request?

Thanks.

Paul Barry (Apr 23 2020 at 23:38):

Brian Carter said:

A question about checking for the existence of a MySL

I refer to the document "DH-3139:2020 - Electronic Prescribing - Conformance Test Specification - Prescribing Systems" issued by the ADHA.
The mandatory conformance requirement PRES-54 states:
"The system SHALL establish whether the SoC has registered for participation in an Active Script List by polling the ASL Registry Services using the SoC’s IHI number, given name and family name."

The sequence diagram – Site with Consent - indicates that the server call "Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&_revinclude=Consent:patient" is required.

My question is how does this fulfill the conformance requirement PRES-54? Does this not also require the patient's name to be included in the request?

Thanks.

Yes this is currently under consideration with ADHA as need to ensure we have the right patient but also don't want to incorrectly return no record due to preferred names, nicknames etc being used by the clinical system. For now I would update your query to include first name and last name but use the "name" property as it has an element of soft matching in there. I will talk to AHDA about firming up the requirement and its implications

Patient?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608166690511&name=Paul&name=Barry&_revinclude=Consent:patient

Paul Barry (Apr 23 2020 at 23:41):

Brian Carter said:

A question about registering a patient.
I refer to Paul Barry's sequence diagram - MySL-Assisted-Reg

image.png

Check required MySL data.
Can someone please point me to where I can find the mandatory data requirements.

Thanks,
Brian.

You can find the patient profile here

https://mysl-hl7-sydney.azurewebsites.net/ig/StructureDefinition-mysl-patient.html

Brian Carter (Apr 24 2020 at 00:11):

@Paul Barry
You can find the patient profile here
https://mysl-hl7-sydney.azurewebsites.net/ig/StructureDefinition-mysl-patient.html

Thanks Paul. Yes, I had seen that document. The only property that is mandatory is the mobile phone number, so then I assume that any other missing data is acceptable.

Paul Barry (Apr 24 2020 at 00:19):

Brian Carter said:

Paul Barry
You can find the patient profile here
https://mysl-hl7-sydney.azurewebsites.net/ig/StructureDefinition-mysl-patient.html

Thanks Paul. Yes, I had seen that document. The only property that is mandatory is the mobile phone number, so then I assume that any other missing data is acceptable.

At this stage the profile is pretty loose as this is just a test server we put together for the connectathon to get feedback from vendors like yourself. I suspect it will tighten as we work with ADHA on conformance. Unfortunately its a moving target and you wont to be able to finalise your solution for a few weeks yet so this test server is really about help you get familiar with the workflows so you can get your system in sync with that and identify any showstoppers. I'll do my best to keep you informed of breaking changes and profile definition changes etc as they occur

Brian Carter (Apr 24 2020 at 06:15):

I have a question about requesting consent to access the MySL.
The consent object has a reference to the organisation. This is shown as a mandatory property on the profile.
Is this something that will change when the security model is implemented? Will this get picked up from the certificate like what is intended when checking if the patient has a MySL and if we have consent?
Or do I need to create an organisation record in order to know the identifier to add into the reference property?
Thanks,
Brian.

Brian Carter (Apr 24 2020 at 06:15):

I have a question about the VerificationResult.
Is there anywhere that defines the requirement for this?
Does the person doing the registration (doctor) need to do some action (eg tick some boxes to indicate some verification that they have done)?
I have seen the sample request at https://mysl-hl7-sydney.azurewebsites.net/ig/guidance-assisted-reg.html, but this does not give any real guidance.
Thanks,
Brian.

John Moehrke (Apr 24 2020 at 14:23):

I am not quite understanding what you expect to get out of adding the "&_revinclude=Consent:patient". This will return ALL consents that have a subject of ALL the patients returned in your query. This would include Consents from other organizations. This will include consents for research projects. This will include consents that are Deny directives. I presume you recognize this and are doing client side processing of these consents?

Paul Barry (Apr 26 2020 at 23:40):

Brian Carter said:

I have a question about requesting consent to access the MySL.
The consent object has a reference to the organisation. This is shown as a mandatory property on the profile.
Is this something that will change when the security model is implemented? Will this get picked up from the certificate like what is intended when checking if the patient has a MySL and if we have consent?
Or do I need to create an organisation record in order to know the identifier to add into the reference property?
Thanks,
Brian.

Hi Brian that's correct this will be picked up by the certificate when the security model is implemented. @Brian Postlethwaite I remember we discussed this, but can you confirm this is correct

Paul Barry (Apr 26 2020 at 23:42):

Brian Carter said:

I have a question about the VerificationResult.
Is there anywhere that defines the requirement for this?
Does the person doing the registration (doctor) need to do some action (eg tick some boxes to indicate some verification that they have done)?
I have seen the sample request at https://mysl-hl7-sydney.azurewebsites.net/ig/guidance-assisted-reg.html, but this does not give any real guidance.
Thanks,
Brian.

Rather than ASL conformance this is really just something that Fred/MediSecure would like. We want to understand or have proof of how the patient was verified/identified. We'll raise this one with ADHA and see if we can firm up the requirement

Paul Barry (Apr 26 2020 at 23:44):

John Moehrke said:

I am not quite understanding what you expect to get out of adding the "&_revinclude=Consent:patient". This will return ALL consents that have a subject of ALL the patients returned in your query. This would include Consents from other organizations. This will include consents for research projects. This will include consents that are Deny directives. I presume you recognize this and are doing client side processing of these consents?

Hi John
Once the security model is implemented, only consent resources for the organisation will be returned i.e. one consent resource or none. The organisation will be implicitly identified by their PKI cert. The MySL will only have one type of consent

Brian Postlethwaite (May 16 2020 at 00:51):

And also, the revinclude just reduces making a second call to check that they have access to the patient. And yes, the filtering will work as noted.

Brian Postlethwaite (May 16 2020 at 00:52):

We're also considering if we should use the patient match operation rather than patient search so that we can apply more appropriate matching on the server side, rather that the explicit ones.

Brian Postlethwaite (May 16 2020 at 00:53):

Practitioners have access to the patients registered with the ASL, but only to meds for one's they are permitted too. That's what the consent tells them.

Brian Postlethwaite (May 16 2020 at 00:54):

This closed system will only have grant permission consents for orgs to matient meds. Nothing else.

Brian Postlethwaite (May 16 2020 at 00:55):

@Brian Carter and @John Moehrke hope the answers above make sense.

John Moehrke (May 18 2020 at 13:14):

How does this system react when the patient changes their mind? That is they have been consented "in", and they decide to go "out", and then they decide to go "in", etc... Is this going to be tracked so that one can know when in vs out happened?

John Moehrke (May 18 2020 at 13:16):

I am also not clear on why the requester would want the consent resource? I understand a access control system that would provide data when the patient has opted in, and provide no data when opted out... but why does the requester want the consent resource when opted in? and why do they not want the consent resource when opted out?

Brian Postlethwaite (May 19 2020 at 04:39):

If they opt out, the data will be gone. - Opt in would look like a new patient

Brian Postlethwaite (May 19 2020 at 04:40):

The requester wants the consent record to know if the search is not providing records because they don't have access to them, vs not having prescriptions. (and what date range they have access to if it was restricted)

Chris Bednarski (Sep 21 2020 at 02:27):

Hi everyone,
I'm new to MySL and have a few questions.

1. Are there any sample C# applications that connect to the server and do self registration/medication request/etc?
2. Is there an active test server available?

Brian Postlethwaite (Sep 21 2020 at 03:12):

I'll check up for you on where the current status is.

Paul Barry (Sep 21 2020 at 03:17):

Hi Chris. Please contact james.nevile@fred.com.au who is the business partner relationship manager at Fred. Once a formal engagement has been agreed, he will invite you to the online documentation and provide access to our test environments

Chris Bednarski (Sep 21 2020 at 03:55):

Paul Barry said:

Hi Chris. Please contact james.nevile@fred.com.au who is the business partner relationship manager at Fred. Once a formal engagement has been agreed, he will invite you to the online documentation and provide access to our test environments

Thanks Paul.

I should have mentioned that I work for Minfos and have already reviewed MySL documentation on https://mysl-hl7-sydney.azurewebsites.net/ig/ . I also have access to https://github.com/Medication-Knowledge/MyScriptList

I was following up on here to see if there are any additional resources that could speed up and simplify the integration process with Minfos

Sandy Xin (Oct 27 2020 at 04:48):

Hi, this is Sandy @Minfos - Dispensing system.
Can anyone assist with the following questions?

1. Re complete MedicationRequest profile
   a. Which attribute indicates the script is ETP1 or ETP2 script?
   b. Which attribute tells us the number of supply fulfilled?
   c. Which attribute indicate the Script Identifier or Barcode/SCID?

Sandy Xin (Oct 27 2020 at 05:19):

Another 2 questions are regarding VerificationResult.

1. we get that we should submit it when registering an ASL account, can you please advise other operations that we need to fire the VerificationResult request after?
   image.png

   

2. Which verificaton of patient's data is mandatory for VerificationResult? Are patient's address and mobile number optional?

Lloyd McKenzie (Oct 27 2020 at 13:26):

1a) What is ETP1 vs. ETP2?
b) MedicationDispense.quantity
c) MedicationDispense.basedOn (which would either be the URL of the prescription or in some cases might just be the identifier

1. Can you provide context for what IG you're referencing
2. That would depend on the IG/business rules

Sandy Xin (Oct 27 2020 at 22:42):

Lloyd McKenzie said:

1a) What is ETP1 vs. ETP2?
b) MedicationDispense.quantity
c) MedicationDispense.basedOn (which would either be the URL of the prescription or in some cases might just be the identifier

1. Can you provide context for what IG you're referencing
2. That would depend on the IG/business rules

Thank you, Lloyd. I am referring to ePrescribing API IG.

Lloyd McKenzie (Oct 27 2020 at 23:10):

Do you have a link?

Brian Postlethwaite (Nov 02 2020 at 06:00):

This is the Australian Guide for our eprescribing capabilities.

Brian Postlethwaite (Nov 02 2020 at 06:05):

The current CI version of the IG can be found here: http://fhir.medicationknowledge.com.au/dev
An EPT2 script's erx/mds identifier will have this type, where the ETP 1 version will not have it

<type>
    <coding>
       <system value="http://hl7.org.au/fhir/v2/0203"/>
       <code value="ETP"/>
    </coding>
    <text value="ETP Identifier"/>
</type>

Alon Hirsch (Mar 17 2021 at 05:27):

Getting started with MySL

I'm new to MySL and FHIR (got access to MySL github and FHIR server etc.from FRED).
I've found the Firely FHIR.Net libraries etc. on github / nuget, but have some questions regarding their use with MySL.
These libraries appear to be for the base (US) implementation of HL7 / FHIR where the resource objects used for MySL are quite different.
Comparing the Patient to MySLPatient - the differences are HUGE, and I was wondering if there is an updated set of DLLs etc. that could be downloaded for use with MySL.
Has anyone converted the requirements to POCOs?
I know that at the end of the day it's all XML or Json, but in code it's obviously much easier to work with objects / POCOs

Thanx,
Alon

Michele Mottini (Mar 17 2021 at 12:49):

What is MySL ?

Alon Hirsch (Mar 17 2021 at 22:26):

MySL - My Script List is the Australian implementation of FHIR, and being tailored specifically to the Australian health environment has extended properties on the different entities like Patient etc.

Lloyd McKenzie (Mar 17 2021 at 22:28):

When you say "extend properties", is it using extensions or is it customizing the resources?

Lloyd McKenzie (Mar 17 2021 at 22:28):

If it's doing the later, it's not actually FHIR - and you won't find a whole lot of people able to help here.

Alon Hirsch (Mar 18 2021 at 00:27):

Lloyd McKenzie said:

When you say "extend properties", is it using extensions or is it customizing the resources?

I'm not really sure - I'd point you to the website with the capability statements etc., but that's down at the moment.
They're claiming it is FHIR, but how it is actually implemented behind the scenes - I cannot actually say.
The Patient object (for example) says it is based on Patient from FHIR, but there are additional properties, slices etc.
In typical OO terms, I would imagine it to be a sub-class of the Patient object
Do you know if there are T4 templates to generate POCOs from XML structure definitions etc.?
I'd be happy to give those a try to see what it could generate - would save me having to try do this all manually?

Lloyd McKenzie (Mar 18 2021 at 01:01):

Slices are fine. Extensions are fine too. I'm not aware of anyone who's currently generating POCOs for specific profiles - it's a very complex exercise.

Lloyd McKenzie (Mar 18 2021 at 01:01):

If they're conformant, everything in the profile should be expressible using the .NET POCOs for the core specification

Gino Canessa (Mar 18 2021 at 15:00):

I'm working on generating compatible classes from Profiles right now, but not using T4. Hopefully have something to show for it soon (TM).

Michele Mottini (Mar 18 2021 at 15:06):

No, profiles are not subclasses - subclasses can add properties to the base class, profiles cannot. Anything that match a profile matches (and can be loaded as) the 'base' FHIR resource

Alon Hirsch (Mar 18 2021 at 22:26):

Michele Mottini said:

No, profiles are not subclasses - subclasses can add properties to the base class, profiles cannot. Anything that match a profile matches (and can be loaded as) the 'base' FHIR resource

Have you seen the MySL profiles?
How would you work with any of the MySL-specific properties using the 'base' FHIR libraries?
Unfortunately, the website is down at the moment (https://mysl-hl7-sydney.azurewebsites.net/) so I cannot refer to anything specific, but for example, from memory, their are different identification attributes - identification:medicare, identification:dva etc. - how would these be specified using the base libraries?

Alon Hirsch (Mar 18 2021 at 22:27):

Gino Canessa said:

I'm working on generating compatible classes from Profiles right now, but not using T4. Hopefully have something to show for it soon (TM).

I'd be very keen to see how you're doing with those.
Doesn't need to be T4, but anything that would help work with the local profiles would help tremendously.
Any idea on an ETA?

Lloyd McKenzie (Mar 18 2021 at 22:34):

If it's identifier:medicare and identifier:dva, it would be no problem, because those are just slices on identifier. You would just use the base identifier structures to define or access instances that happen to meet the constraints of those particular slices.

Michele Mottini (Mar 18 2021 at 22:47):

Alon, if it is a profile of a FHIR resource by definition of what a profile is the data can be handled using the standard POCO classes (for that same FHIR version)

Alon Hirsch (Mar 19 2021 at 00:02):

Michele Mottini said:

Alon, if it is a profile of a FHIR resource by definition of what a profile is the data can be handled using the standard POCO classes (for that same FHIR version)

The StructureDefinition for MySLPatient can be seen here: https://fhir.medicationknowledge.com.au/dev/StructureDefinition-mysl-patient.html
Any code (C# preferably) sample showing how I would create / update a patient with the MySL-specific fields would be greatly appreciated

Richard Townley-O'Neill (Mar 19 2021 at 02:35):

@Brett Esler @Danielle Bancroft

Gino Canessa (Mar 19 2021 at 17:45):

Alon Hirsch said:

Gino Canessa said:

I'm working on generating compatible classes from Profiles right now, but not using T4. Hopefully have something to show for it soon (TM).

I'd be very keen to see how you're doing with those.
Doesn't need to be T4, but anything that would help work with the local profiles would help tremendously.
Any idea on an ETA?

Not yet, unfortunately. The code generation shouldn't take long once I've settled on the output shape, but getting a 'dev-friendly' set of outputs is taking some tinkering (especially for complex extensions.. yuck). I'm starting with C#, so I'll post in the dotnet stream once I have something ready for feedback.

Michele Mottini (Mar 19 2021 at 23:08):

Here is an example of a standard POCO Patient with a couple of those MySL-specific 'field':

            var patient = new Patient
            {
                Identifier = new List<Identifier>
                {
                    new Identifier  // identifier:medicare
                    {
                        System = "http://ns.electronichealth.net.au/id/medicare-number",
                        Value = "THIS IS THE MEDICARE IDENTIFIER"
                    }
                },
                Telecom = new List<ContactPoint>
                {
                    new ContactPoint    // telecom:mobileNumber
                    {
                        Use = ContactPointUse.Mobile,
                        Value = "THIS IS THE MOBILE PHONE NUMBER"
                    }
                }
            };

Gino Canessa (Mar 20 2021 at 20:14):

Thanks Michele - the thorny part I'm tinkering with right now is around complex extensions. I have been trying to overlay something that keeps the underlying objects correct and provides a good developer experience.

Using C# class extensions gets confusing, since there is no way to filter 'inner' extensions off the outer layers (e.g., in US Core, ombCategory becomes available to Patient.Extension as well as the desired Patient.Extension[us-core-race]). I think the answer is just generating classes for complex extensions that have internal structures and sync with the underlying model instead of using it directly, but need a little more work to sort it out.

Michele Mottini (Mar 21 2021 at 00:38):

I don't think it is a good idea to write such code generator. It perpetuates this wrong idea that to work with profiles you NEED something special (that I keep seeing). It potentially hinders interoperability: real servers return data conforming to different profiles, or no profiles, mixed together - and once you write your client using a profile-specific library you'll be in trouble interpreting the data you get back.

Lloyd McKenzie (Mar 21 2021 at 01:24):

It's useful for single-purpose clients that want to keep their interfaces as simple as possible - and enforce most of the profile the constraints at compile time. Agree that it will have more questionable usefulness on a general purpose basis.

Gino Canessa (Mar 21 2021 at 02:21):

One of the topics I get asked about the most is working with profiles. As I started working through why, I realized they have a terrible dev experience.

Here’s an IG that has several profiles. Each profile has (among validation changes) often multiple extensions. Some of those extensions have multiple extensions of their own.

To use this IG, copy a bunch of URLs from it, then iterate over collections to put everything in the right place. Also, you get no type hinting, since extensions can be of any type.

I disliked it enough that my reaction to trying to record a tutorial was to start building out tooling.

Josh Mandel (Mar 21 2021 at 03:45):

to be clear, this isn't about "single-purpose clients" -- it's about clients that want to say: here's a pile of extensions (some simple, some complex) that I want to interact with in a first-class way, when they're present. It doesn't limit what you can do and doesn't assume that all data you see will fit these profiles.

Josh Mandel (Mar 21 2021 at 03:46):

My take: the developer experience for working with simple extensions is clunky but okay; if you want to work with complex extensions, you basically need to create your own management tools to keep things sane -- so why not create these in general-purpose framework, if you need to create them in the first place?

Josh Mandel (Mar 21 2021 at 03:47):

(If you disagree with this assessment: show me your code for working with US Core Race extensions -- say, code that clusters patients into groups based on race, or displays a coded + textual description for a clinician in a face sheet.)

Michele Mottini (Mar 22 2021 at 13:11):

say, code that clusters patients into groups based on race, or displays a coded + textual description for a clinician in a face sheet.

You seems to assume that real system work with data represented as FHIR, but this is not the case: real system have their own internal data representation, what you need to do is just to convert back and forth - that even for the US core race and ethnicity extensions is trivial

Josh Mandel (Mar 22 2021 at 15:53):

I'm not assuming anything uses FHIR internally (though... an increasing number of systems do, and we can talk about trade-offs there). In my list of "show me the code" requests, I could just as well add: "show me your code for mapping from FHIR US Core Race into your internal representations". My point is only that the nested extension syntax makes the ergonomics of using (filtering, extracting, converting...) these data more challenging. (You may be right that the pain is worse for systems trying use FHIR structures natively, but that's not my focus(

Michele Mottini (Mar 22 2021 at 17:39):

This handles US Core and Argonaut race and ethnicity in both directions - around 100 lines of code:

    public class USCoreCodeableConceptExtensionPropertyMapper<TResource, TConcept> : ExtensionPropertyMapper<TResource, TConcept>
        where TResource : FhirModel.DomainResource
    {
        public USCoreCodeableConceptExtensionPropertyMapper(
            string extensionUrl,
            string system,
            string[] ombCodes,
            string nullFlavorSystem,
            string[] ombNullFlavorCodes,
            Expression<Func<TConcept, Term>> termPropertyExpression,
            Expression<Func<TConcept, Term>> alternateTermPropertyExpression,
            Expression<Func<TConcept, string>> textPropertyExpression
        ) : base( extensionUrl )
        {
            if ( string.IsNullOrEmpty( system ) ) throw new ArgumentNullException( nameof( system ) );
            if ( ombCodes == null || ombCodes.Length == 0 ) throw new ArgumentNullException( nameof( ombCodes ) );

            _system = system;
            _ombCodes = ombCodes;
            _nullFlavorSystem = nullFlavorSystem;
            _ombNullFlavorCodes = ombNullFlavorCodes;
            _helper = new CodeableConceptPropertyMapperHelper<TConcept>( termPropertyExpression, alternateTermPropertyExpression, textPropertyExpression );
        }

        public override void Map( ToFhirMapper mapper, TConcept source, FhirModel.Extension destination )
        {
            var codeableConcept = _helper.CreateCodeableConcept( mapper, source );
            destination.Extension = CreateArgonautEthnicityOrRace( codeableConcept );
        }

        public override void Map( FromFhirMapper mapper, FhirModel.Extension source, TConcept destination )
        {
            if ( source == null ) return;

            var ombCoding = source.Extension.FirstOrDefault( e => e.Url == ExtensionUrl.ArgonautEthnicityOrRaceOmbCategory )?.Value as FhirModel.Coding;
            if ( ombCoding != null && !IsValidOmbCoding( ombCoding ) )
            {
                mapper.Context.Warning( new FhirBadDataException(
                    "Invalid '{2}' extension coding value ('{3}|{4}') for '{0}' {1} extension",
                    _extensionUrl,
                    MappingHelper.GetResourceType<TResource>(),
                    ExtensionUrl.ArgonautEthnicityOrRaceOmbCategory,
                    ombCoding.System,
                    ombCoding.Code
                ) );
                return;
            }

            var textValue = source.Extension.FirstOrDefault( e => e.Url == ExtensionUrl.ArgonautEthnicityOrRaceText )?.Value as FhirModel.FhirString;
            if ( textValue == null )
            {
                mapper.Context.Warning( new FhirBadDataException(
                    "'{2}' extension required for '{0}' {1} extension",
                    _extensionUrl,
                    MappingHelper.GetResourceType<TResource>(),
                    ExtensionUrl.ArgonautEthnicityOrRaceText
                ) );
                return;
            }

            var detailedCoding = source.Extension.FirstOrDefault( e => e.Url == ExtensionUrl.ArgonautEthnicityOrRaceDetailed )?.Value as FhirModel.Coding;

            var mainCoding = ombCoding ?? detailedCoding;
            var alternateCoding = ombCoding != null ?
                detailedCoding :
                null;
            _helper.SetFromCodingsDefaultToUndefined( mapper, destination, mainCoding, alternateCoding, textValue.Value );
        }

        /// <summary>
        /// Creates the special Argonaut / US core ethnicity or race extensions from the corresponding generic CodeableConcept -
        /// see https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-ethnicity.html
        /// and https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-race.html
        /// </summary>
        private List<FhirModel.Extension> CreateArgonautEthnicityOrRace( FhirModel.CodeableConcept codeableConcept )
        {
            if ( string.IsNullOrEmpty( codeableConcept?.Text ) ) return null;

            var result = new List<FhirModel.Extension>
            {
                new FhirModel.Extension( ExtensionUrl.ArgonautEthnicityOrRaceText, new FhirModel.FhirString( codeableConcept.Text ) )
            };

            if ( codeableConcept.Coding != null )
            {
                result.AddRange(
                    codeableConcept.Coding
                        .Where( coding => coding != null && coding.System == _system )
                        .Select( coding => new FhirModel.Extension(
                            _ombCodes.Contains( coding.Code ) ? ExtensionUrl.ArgonautEthnicityOrRaceOmbCategory : ExtensionUrl.ArgonautEthnicityOrRaceDetailed,
                            coding
                        ) )
                );
            }

            return result;
        }

        private bool IsValidOmbCoding( FhirModel.Coding ombCoding )
        {
            return ombCoding.System == _system && _ombCodes.Contains( ombCoding.Code )
                || _nullFlavorSystem != null && ombCoding.System == _nullFlavorSystem && _ombNullFlavorCodes.Contains( ombCoding.Code );
        }

        private readonly string _system;
        private readonly string[] _ombCodes;
        private readonly string _nullFlavorSystem;
        private readonly string[] _ombNullFlavorCodes;
        private readonly CodeableConceptPropertyMapperHelper<TConcept> _helper;
    }

Josh Mandel (Mar 22 2021 at 17:43):

Perfect, that's exactly the kind of thing I'm thinking about. Did you create this USCoreCodeableConceptExtensionPropertyMapper with functions like CreateArgonautEthnicityOrRace by hand, or through code generation?

Michele Mottini (Mar 22 2021 at 18:11):

By hand

Gino Canessa (Mar 22 2021 at 18:40):

Michele Mottini said:

By hand

This. I think there should be tooling to give someone the option of not writing and maintaining that code.

Michele Mottini (Mar 22 2021 at 19:08):

Gino, did you look at that code? There is no way it can be auto-generated by something generic - a small piece of it _could_ be, but then we'd have to duplicate the whole thing one for Argonaut and one for US core

Gino Canessa (Mar 22 2021 at 19:10):

I did, what makes you say it cannot be generated? It is no harder than generating the core model definitions.

Josh Mandel (Mar 22 2021 at 19:11):

I think @Michele Mottini is referring to the fact that this code helps with two similar but distinct definitions (one from US Core, and one from the older Argonaut profiles that fed into US Core work)

Josh Mandel (Mar 22 2021 at 19:12):

Which is a fair point, but Michele's code would look almost as complex even if it was just targeting US Core Race (which was my initial quesiton). So I'm not saying auto-generated code can do everything hand-written code can do... but it can cut out a lot of the complexity, and if you had access to high-quality auto-generated code for US Core + (separately) Argonaut extensions, then writing the wrapper (by hand) to unify/map between these could be done fairly cleanly on top.

Michele Mottini (Mar 22 2021 at 19:19):

I did, what makes you say it cannot be generated?

??? Most of those 100 lines are specific to our implementation, have nothing to do with model definition and so cannot be auto-generated by some code that looks at structure definition.
What a code generator would help with is changing:

           var ombCoding = source.Extension.FirstOrDefault( e => e.Url == ExtensionUrl.ArgonautEthnicityOrRaceOmbCategory )?.Value as FhirModel.Coding;

into something like:

      var obbCoding = source.USCoreRace

so simplify a couple of lines of that 100 - at the cost of making the class specific to US Core race (and so having 4 classes instead of one)

Josh Mandel (Mar 22 2021 at 19:31):

These (together with the code for extracting the top level extensions that these use as inputs) are good examples that we can use to evaluate what codegen can (and can't) help with. If others have examples of code for dealing with specific complex extensions, that'd be great to share here too.

Gino Canessa (Mar 22 2021 at 20:18):

Perhaps I did not read closely enough. To me, it appeared (with an admittedly quick read), that a fair amount code was around actually interfacing with the extensions, checking systems, etc.. If you have generated code that lets you use patient.UsCoreRaceExtension, patient.ArgonautRaceExtension, etc., you end up with mapping which is much shorter - this is primitive and incomplete since I don't have all the generated code behind it, but validating all UsCoreRace values were present as ArgonautRace values could be something like:

                foreach (UsCoreRaceExtensionWrapper usCoreRaceExt in patient.UsCoreRaceExtension)
                {
                    if (patient.ArgonautRaceExtension.Where((argoRaceExt) => argoRaceExt.ombCategory == usCoreRaceExt.ombCategory).Any())
                    {
                        continue;
                    }

                    patient.ArgonautRaceExtension.AddArgonautRaceExtension(usCoreRaceExt.ombCategory, usCoreRaceExt.detailed, usCoreRaceExt.text);
                }

Having generated code allows for things like using an enum for ombCodes (since it is a required binding), which is a nice quality of life improvement and reduces the need for some of the external validation steps.

I will also note that your sample code has external dependencies in your code to simplify it (e.g., ExtensionUrl.ArgonautEthnicityOrRaceOmbCategory), which is part of the pain point I am looking to address. Sorting through IGs to find all the URLs, set up a hierarchy for them that makes sense, keep track of the correct value type for each, etc.; there is a lot of work and mental load for (especially new) developers here.

Eventually, I am hoping to have calls like patient.AsUsCorePatientProfile.IsValid(), so you can see if a patient conforms to a given profile (this is, of course not part of v1 =). Since it is just a wrapper around the basic Patient class, you would be able to call something like patient.AsIpsPatient.IsValid() on the same instance.

Yes, there is additional code behind. I don't think it is different from what you are doing here by generating your own internal convenience classes.

Michele Mottini (Mar 22 2021 at 21:18):

Guys, I don't know what else to say - do as you like (of course)

Gino Canessa (Mar 22 2021 at 21:42):

Michele, as always! =).

I hope I am not being too contentious - I am genuinely trying to understand your objection. From what I hear (and I assume from your initial comment on this thread that you hear as well), many people struggle to work with IGs, Profiles, Extensions (especially complex ones), etc. To me, that indicates that there is a problem of some kind.

I am not arguing that the only way to work with these artifacts is additional code generation, but that working with them is currently painful enough that it is a problem. To me, additional work in this space is is no different than the existence of the various language libraries, and if we can build a 'good enough' system in various languages, I would eventually PR the work back into them.

The way I see it, while it's perfectly valid (and often useful) to make direct HTTP calls with no external libraries, if that was the only way to use FHIR the community would be poorer.

Danielle Bancroft (Mar 23 2021 at 03:08):

Lloyd McKenzie said:

When you say "extend properties", is it using extensions or is it customizing the resources?

The MySL profiles are all standard R4 with AU base and proper extensions. MySL was implemented by myself and @Brian Postlethwaite and is NOT customized resources. The MySL is a national implementation for Australia. Alon unfortunately had the old POC IG instead of the actual active IG

Alon Hirsch (Mar 23 2021 at 04:34):

Michele Mottini said:

Here is an example of a standard POCO Patient with a couple of those MySL-specific 'field':

            var patient = new Patient
            {
                Identifier = new List<Identifier>
                {
                    new Identifier  // identifier:medicare
                    {
                        System = "http://ns.electronichealth.net.au/id/medicare-number",
                        Value = "THIS IS THE MEDICARE IDENTIFIER"
                    }
                },
                Telecom = new List<ContactPoint>
                {
                    new ContactPoint    // telecom:mobileNumber
                    {
                        Use = ContactPointUse.Mobile,
                        Value = "THIS IS THE MOBILE PHONE NUMBER"
                    }
                }
            };

Awesome! Thanx Michele - help me with a great starting point

Alon Hirsch (Mar 23 2021 at 04:36):

Gino Canessa said:

Alon Hirsch said:

Gino Canessa said:

I'm working on generating compatible classes from Profiles right now, but not using T4. Hopefully have something to show for it soon (TM).

I'd be very keen to see how you're doing with those.
Doesn't need to be T4, but anything that would help work with the local profiles would help tremendously.
Any idea on an ETA?

Not yet, unfortunately. The code generation shouldn't take long once I've settled on the output shape, but getting a 'dev-friendly' set of outputs is taking some tinkering (especially for complex extensions.. yuck). I'm starting with C#, so I'll post in the dotnet stream once I have something ready for feedback.

Looking forward to that - thanx Gino

Brian Postlethwaite (Mar 23 2021 at 10:00):

Sorry I missed all this, and yes it's an R4 fhir implementation.
The IG is now here :
https://fhir.medicationknowledge.com.au/dev/

Brian Postlethwaite (Mar 23 2021 at 10:01):

And yes, as long as you use the R4 fhir client (from Firely) then you're all good, that's how we test it, and it's implemented in dotnet on sql server too (and is internally fhir content too)
We have other non fhir systems that contribute to its content also.

Alon Hirsch (Mar 23 2021 at 23:50):

Brian Postlethwaite said:

And yes, as long as you use the R4 fhir client (from Firely) then you're all good, that's how we test it, and it's implemented in dotnet on sql server too (and is internally fhir content too)
We have other non fhir systems that contribute to its content also.

Thanx @Brian Postlethwaite - much appreciated

Sam-S4S (Sep 24 2021 at 01:52):

Hello, is anyone here able to answer some questions regarding some of the JWT fields?

Daniel Venton (Sep 24 2021 at 12:21):

You might try the #smart stream instead of a management stream.

Brian Postlethwaite (Sep 25 2021 at 01:29):

Is that specific to the Australian eprescribing stuff?

Sam-S4S (Sep 29 2021 at 02:51):

Daniel Venton said:

You might try the #smart stream instead of a management stream.

Ah, ok. We were pointed here by someone at eRx / Fred.
Brian Postlethwaite said:

Is that specific to the Australian eprescribing stuff?

Indeed it is!

Brian Postlethwaite (Oct 03 2021 at 21:50):

What's the question?
That JWT is Fred IT specific I think, and details should be in the spec listed above.

Last updated: Apr 12 2022 at 19:14 UTC