Patient Administration WG
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata

FHIR implementation guide for provider directory interfacing in an Australian Context

Web Conference Details

HL7 AU PA WG & SM TWG Joint  

Every 2 weeks Thu, 11:30 AM - 12:30 PM AEDT 

Next Meeting:  

PC, Mac, Linux, iOS or Android: https://zoom.us/j/7479215691

or Phone: +61 (0) 2 8015 2088, Meeting ID: 747 921 5691



Specification

http://build.fhir.org/ig/hl7au/au-fhir-pd - Australian Provider Directory Profile FHIR Implementation Guide; draft material (constant integration build); this version my be inconsistent at times

http://hl7.org.au/fhir - Australian Provider Directory Profile FHIR Implementation Guide snapshots for event/connectathons are listed here; these are published to be stable for use during events 

Reference Material

http://hl7.org/fhir/index.html - FHIR (STU3) core specification that is the basis of implementation guide work. It contains all core material for FHIR usage and also references tooling, open source projects, reference server implementations, testing tools and community material.

https://chat.fhir.org/ - The main instant messaging chat channel using the Zulip tool for international participation.  This contains many streams of conversation on FHIR specifications, implementation and usage.  There is an ‘australia’ channel focused on Australian context and many other channels of interest, commonly used for discussion, questions/answers and announcements.

http://hl7.org.au/fhir - Directory of FHIR Implementation Guide versions including AU Base FHIR Implementation Guide and AU PD Implementation Guide; the provider directory IG depends on the AU Base FHIR IG content (derives from).

http://build.fhir.org/ig/Healthedata1/Argo-PD/ - US Argonaut project draft documentation related to work undertaken by Argonaut vendors and the ONC provider directory workshop.  Offers international perspective on provider directories functionality. 

Example Provider Directory Search

Connectathons

Workshops

Meetings


9 Comments

  1. Brett Esler

    Things to talk about from the connectathon

    • Provider role terminology updates from NHSD; Update on preferred coding from Patient Administration working group.
    • Search on HeathcareService name is not that useful - we should just support chained search ?organization.name=XXXX
    • Local directory synchronisation patterns and requirements 
    • CapabilityStatement for the AU PD profile (examples aligned with the profiles)
    • Endpoint content fit for use?  Can we use current content to address for SMD?
    • Discussion items around constraints that may affect other (non SM) related provider directory use
    • Non-healthcare Organizations/HealthcareServices appropriate identifiers and certificates for these entries (GSO, CSP, PAI-O, vendor certificates)
    • Security, Authentication and Authorisation scenarios - minimal; typical; possible

  2. Jaco

    Brett Esler -

    As discussed last week at the Connectathon - just adding the notes hereto:

    While reviewing the HealthcareService resource, we identified that the support for "eligibility" is somewhat limited - as the multiplicity is 0..1 and the "note" is stored separately...

    Wondering if it would be possible to make a recommendation to HL7 International (or implement a Complex Extension as part of AU-BASE if not accepted) as follows:

    • it is possible and common for some services to have more than one eligibility, with different notes:

    I am proposing an improvement with a more supportive Eligibility structure:

    eligibility 0..* Eligibility



where "Eligibility" is defined as:
.. eligibility		  0..1	CodeableConcept	Specific eligibility requirements required to use the service
.. eligibilityNote	  0..1	String

    1. Brett Esler

      Thanks Jaco - what are some examples for this element?

      1. Jaco

        Apologies Brett - I missed your question on this comment. Here are two samples, each with a different method of modelling it.

        Option B is over engineered.

        // Sample Record A - text based Eligibility Criteria (eligibilityNote)
// defined  as a HealthcareService which provides it services to only Women patients, which have an Intellectual or Physical disability
"eligibility": [
	{
		"eligibility":     {
			"coding": {
				"system":".../accessibilityType",
				"code":"gender",
				"display":"Gender"
			},
			"text": ""
		},
		"eligibilityNote": "Women"
	},
	{
		"eligibility":     {
			"coding": {
				"system":".../accessibilityType",
				"code":"disability",
				"display":"Disability"
			},
			"text": ""
		},
		"eligibilityNote": "Intellectually, Physically"
	}	
]
        Option B 
        // Sample Record B - CodeableConcept based Eligibility Criteria as a defined attribute (Note)
// this technique may be over engineered - was provided for context
// defined  as a HealthcareService which provides it services to only Women patients, which have an Intellectual or Physical disability
"eligibility": [
	{
		"eligibility":     {
			"coding": {
				"system":".../accessibilityType",
				"code":"gender",
				"display":"Gender"
			},
			"text": ""
		},
		"eligibilityCriteria":     {
			"coding": {
				"system":".../accessibilityTypeGender",
				"code":"women",
				"display":"Women"
			},
			"text": ""
		},		
		"eligibilityNote": ""
	},
	{
		"eligibility":     {
			"coding": {
				"system":".../accessibilityType",
				"code":"disability",
				"display":"Disability"
			},
			"text": ""
		},
		"eligibilityCriteria":     {
			"coding": {
				"system":".../accessibilityTypeDisability",
				"code":"intellectually",
				"display":"Intellectually"
			},
			"text": ""
		},			
		"eligibilityNote": ""
	},
	{
		"eligibility":     {
			"coding": {
				"system":".../accessibilityType",
				"code":"disability",
				"display":"Disability"
			},
			"text": ""
		},
		"eligibilityCriteria":     {
			"coding": {
				"system":".../accessibilityTypeDisability",
				"code":"physically",
				"display":"Physically"
			},
			"text": ""
		},			
		"eligibilityNote": ""
	}		
]

  3. Jaco

    Brett Esler - 

    As per the discussion last week - the ContactPoint resource has the "use" attribute, bound to the valueSet (http://hl7.org/fhir/ValueSet/contact-point-use)

    Supporting basically only, home and work.

     

    Within the NHSD, there are more "contactPurposes" in use - and think that many other directories may have more context than just home / work.

    Should we have to "map" all of our purposes to the current HL7 valueSet, I believe we would be losing a lot of context, however the data would still be accurate.

     

    defaultContact (-- this could be "work" --)
admission
afterHours
billingAndPayment
crisisLine
... and a few more

     

    Would you agree that we look into the AU-BASE profile and allow for this "valueSet" to be extensible (1), or define a more detailed/supportive valueSet (2) for "contact-point-use"

     

     

    1. Brett Esler

      Thanks - is that for HealthcareService.telecom? 

      1. Jaco

        The example was mostly focused towards HealthcareService.telecom, however an extensible (or AU-BASE) set of contactPurposes may also be applicable to Organization and even ProviderLocation.

  4. Kieron McGuire

    Can a link to the static version for the September2017 connectathon be added to the Specifications section?

    1. Brett Esler

      done now