Stream: new zealand
Topic: Local Extensions
Peter Jordan (Sep 10 2018 at 02:28):
HL7 New Zealand and partners are interested in identifying the current and proposed use of FHIR extensions in NZ. All implementers of Kiwi-based FHIR solutions on this thread are invited to contribute... @David Hay , @Daniel Thomson , @David Moorhouse , @David Fallas , @Alastair Kenworthy , @Abdul Rauf , @Graeme Hibbert , @Nate Walker , @John Carter , @Dan Lord , @Ben Gray , @Chandan Datta , @Koray Atalag , @Ray Murakami , @Martin Entwistle , @Chris Hilder , @David Teirney , @Jason Marshall ... and others including, of course, our friends from over 'The Ditch'.
Mohannad Hammadeh (May 27 2019 at 04:05):
Hi @Peter Jordan , how can i find what extensions have been identified so far? I'm looking for extensions for Ethnicity, Quintile and Domicile DHB
Peter Jordan (May 27 2019 at 05:43):
Hi @Mohannad Hammadeh - @David Hay who is working on a FHIR API for the NHI is probably best placed to answer this question. I would definitely expect to see an 'official' extension for NZ Ethnicity to be part of that work. I'd be interested to know what project requires Quintile and Domicile DHB to be transferred as they can be calculated from addresses (certainly by all the primary care systems).
Mohannad Hammadeh (May 27 2019 at 21:59):
@David Hay is working on it! Awesome, I should check clinfhir then.
David Hay (May 27 2019 at 23:25):
Hi Mo! The work is documented at http://nz.clinfhir.com/ and you're right - I'm using clinFhir to model this. Feel free to comment - it's all draft at this stage...
BTW - this work will be a focus at the upcoming HL7 NZ Connectathon (https://sites.google.com/a/hl7.org.nz/hl7-new-zealand/news/hl7nzmid-yearseminar) - would be great to see you (and anyone else interested in this stuff) there! It will be deeply technical, and we'll have the MOH folk there to engage in discussion about what should be in - or out - of the queries...
Mohannad Hammadeh (May 28 2019 at 00:06):
Hi Dr Hay! That is almost exactly what we're after. Thank you. I think you covered all the extensions that we need in that profile, but I've got a couple of questions.
1. Patient.address.suburb - is that a fhir element? i dont see it under https://www.hl7.org/fhir/STU3/datatypes.html#Address
2. The elements under the geoCode extension, say for example deprivationQuintile, would the URL be http://hl7.org.nz/fhir/StructureDefinition/nzGeoCode#deprivationQuintile ?
Will have to double check about the connectathon ;)
David Hay (May 28 2019 at 01:12):
excellent! - Just remember that most of these are proposed though. Plan is to put them out for comment, so be prepared to change :)
David Hay (May 28 2019 at 01:12):
You're right about suburb - my bad...
David Hay (May 28 2019 at 01:14):
wrt quintile, the url to the complex extension would just be http://hl7.org.nz/fhir/StructureDefinition/nzGeoCode. The child elements are (will be) defined within that SD... Fingers Xed that you can make the connectathon - be very good to have an Orion person there...
David Hay (May 28 2019 at 01:23):
BTW - working on some samples to help validate the models. See
home.clinfhir.com:8054/baseR4/Patient/patient2
home.clinfhir.com:8054/baseR4/Practitioner/practitioner1
home.clinfhir.com:8054/baseR4/Organization/organization1
home.clinfhir.com:8054/baseR4/Location/location1
Usual disclaimer! Also - none of the extension definitions are built yet. Would like to agree on the naming conventions first...
Mohannad Hammadeh (May 28 2019 at 02:07):
Yes i did think they were proposed at this stage. Is there a way we can get them reviewed and finalised relatively soon? I'd like to get the project team to use something standard instead of coming up with their own.
Mohannad Hammadeh (May 28 2019 at 02:15):
Those samples are looking good! Is there anywhere we can collaborate/provide feedback on them?
David Hay (May 28 2019 at 02:57):
Always interested in collaborators :) - what kind of feedback were you thinking of? You could just make comments here if you like - or to my email, whatever works best for you...
Peter Jordan (May 28 2019 at 03:28):
I think that it would be preferable if discussions about national FHIR extensions took place in an open forum, such as this. I'd also suggest that implementers make the base URL a configurable property for the time being, until a final decision has been reached on this.
David Hay (May 28 2019 at 05:09):
The urls will be agreed before any production deployment I would imagine - indeed, I'd hope to have that done sooner rather than later...
The current urls are visible in the models at nz.clinfhir.com (as will, of course, the 'real' fhir IGs that will be generated from them). Of course, it's all draft at this point, but anyone can comment either against the models, in this forum or privately (if that is what they want - not everyone is comfortable posting in an open forum!). But any proposed artefacts will always be publicly available...
I'm working on getting some summary views of the extension /valueset / codesystem urls available to make it easier to review them - I'll upload and paste a link here when that's done
I'm hoping that the upcoming connectathon will be the impetus to get the community involved in this...
Mohannad Hammadeh (May 28 2019 at 22:01):
@Peter Jordan it's a bit tricky for the extensions to be made configurable as it's not only the URLs that would have to be configurable but also the structure and position of the extension. Also if we go into production with temporary extensions and various applications end up consuming them it would make it difficult to standardise the extensions in the future.
Mohannad Hammadeh (May 28 2019 at 22:02):
@David Hay do we have a date for when we'd expect production deployments?
Mohannad Hammadeh (May 28 2019 at 22:11):
@David Hay one bit of feedback about the naming of extensions is that fhir seems to follow the naming pattern of <resource>-<extensionName>, for example: (from https://www.hl7.org/fhir/R4/patient-profiles.html)
- patient-adoptionInfo
- patient-animal
- patient-birthPlace
- patient-birthTime
- patient-cadavericDonor
Should we follow that pattern for the nz extensions? so
http://hl7.org.nz/fhir/StructureDefinition/nzDhb -> http://hl7.org.nz/fhir/StructureDefinition/patient-nzDhb
http://hl7.org.nz/fhir/StructureDefinition/nzethnicity -> http://hl7.org.nz/fhir/StructureDefinition/patient-nzEthnicity
David Hay (May 28 2019 at 22:26):
That's certainly one of the questions that would be good to get input on. It does assume that a single extension is only used in a single resource though (at least from a naming perspective)...
Given the the current stuff I'm working on is specifically an interface to NHI/HPI, I've started using that as the prefix - eg http://hl7.org.nz/fhir/StructureDefinition/hpiPractitionerRegistration for the HPI registration extension.
I don't have a strong opinion - but would be great to get others thoughts!
(btw - if you want to see all the extensions in a model, go to the 'analysis' tab, then 'Extensions'. You'll get a display of all extensions in a model, hyperlinked to the element definition)
Peter Jordan (May 28 2019 at 22:41):
Domicile DHB and Deprivation Quintile are not direct patient attributes - they are attributes of an (NZ) address, calculated according to non-immutable criteria (e.g. DQs are re-calculated after each census and I doubt if the current structure of 20 DHBs will exist for too much longer). I find it hard to envisage any future national HIE project based on FHIR that will require these. Certainly the National Enrolment Service performs the calculations internally (i.e. no longer requires general practices to send it as part of the patient register for CBF payment purposes- and then deal with thousands of errors!) and, for obvious reasons, these fields will never be part of the GP2GP Data Model.
David Hay (May 28 2019 at 22:52):
Well that's true - but the address is an attribute of patient, which is why they are modelled as extensions on address (you could argue that the name could reflect that better). As to whether they should be included at all? well, that's really a matter for the MOH team to decide (in this case) - there are many different users of the NHI service, and it may be that supplying this data in the response, rather than requiring them to look it up themselves is useful...
Peter Jordan (May 28 2019 at 22:58):
Agree that any extensions based on address should be named accordingly. Most NZ healthcare facilities do address mapping , querying and validation via eSAM Web Services... https://www.health.govt.nz/system/files/documents/pages/hip_address_services_integration_guide_v8.0.pdf
These return DQs, DHB district, etc.
Anne Goodwin (May 28 2019 at 23:22):
A person's DHB is determined by where they usually reside and generally that can be derived from the address. However, sometimes an actual address is not available (eg person has no fixed abode, their address is new and not in any reference data yet, person resides overseas). Putting DHB as an attribute of patient means that the NHI can manage all those exception rules and reduce effort on the part of the integrator. I think it fits better on the patient than the address because a patient may have multiple addresses (residential, mailing, temporary address) but they only have one DHB.
Peter Jordan (May 28 2019 at 23:49):
Interesting, what determines which DHB a patient is linked to if they have no address or multiple addresses?
David Hay (May 28 2019 at 23:49):
So there's 2 extensions on address - geocode, and notValidated reason. how about:
http://hl7.org.nz/fhir/StructureDefinition/patient-address-geoCode or just http://hl7.org.nz/fhir/StructureDefinition/address-geoCode ?
Peter Jordan (May 28 2019 at 23:51):
Prefer the later as the address might be be used by resources other than Patient, e.g. Location.
Grahame Grieve (May 28 2019 at 23:53):
http://hl7.org/fhir/StructureDefinition/geolocation
David Hay (May 29 2019 at 02:16):
Hmm. missed that...
Patrick Ryan (May 29 2019 at 03:41):
The eSAM address service used by MoH returns lat longs using the New Zealand Geodetic Datum 2000 (NZGD2000) :
https://www.health.govt.nz/system/files/documents/pages/hip_address_services_integration_guide_v8.0.pdf
http://hl7.org/fhir/StructureDefinition/geolocation uses the WGS84 datum used by GoogleMaps. I think these are very similar but not identical. We might want an extension to allow us to be specifc about the datum
Brian Postlethwaite (Jun 03 2019 at 12:14):
That's a very good bit of information, and maybe that's the difference to what is in your extension, so if folks want to use the standard one, they can perform the co-ordinate system conversion.
David Hay (Jun 03 2019 at 19:07):
If it's possible to convert between the 2 algorithmically, then would it be better that the NHI service perform the conversion and use the standard extension? Or - should the datum be added to the standard extension?
Brian Postlethwaite (Jun 04 2019 at 01:05):
I personally would prefer not to have to check the datum value too.
(lazy programmer)
David Hay (Jun 04 2019 at 05:16):
But - if I understand the issue - doesn't that mean that the datum is implicit? (lazy = efficient!)
Brian Postlethwaite (Jun 04 2019 at 05:38):
Those extensions are implicitly that datum. Which is also the same one used in many major maps providers.
David Hay (Jun 04 2019 at 05:45):
So we (NZ) have our own datum? Bother. That suggests that either we convert when using the extension, extend the extension or create another one...
Last updated: Apr 12 2022 at 19:14 UTC
