As per “Location” entity, particularly confidentiality
Expand email to include name, description and confidentiality
Expand eligibility to at least same as ISS
Incorporate ineligibility
Consider “intake” information, including location (may be different than service) such as an “access point”.
Collaborate on approach to handling the subtle differences in jurisdictional requirements like licenses and the many various low income support scheme accreditations. Eg In Australia we have NDIS and a national “Health care card”, national “Veterans card”. This all seems like considerations that should be separate objects under one “support” or “entitlement” or similar parent object. Seems distinct (legally) from accreditation though.
Include tax number / details for service (to assist in claims, if relevant)
Collaborate on including more demographic suitability, eg:
Indigenous peoples support (where special programs exist for this)
Gender specific services
LGBT specific services (or where special support is offered)
Age specific services (pre/neo-natal and maternal, youth, aged etc).
Consider expanding location as per ISS site (in service) to facilitate end system display
Consider adding a dataset objects field
Add a last updated field
Consider adding more methods to retrieve only components and summary information for services as per HSDA methods
Consider electronic referral systems and how they may use this system as a directory. ISS incorporates the concept of a service “endpoint” which holds a list of dictionary items with type of referral and the relevant endpoint. This could expanded to hold all information required to send a referral electronically.
Consider interoperability with other directory services.
dan-odsc
commented
7 months ago
As per “Location” entity, particularly confidentiality Expand email to include name, description and confidentiality Expand eligibility to at least same as ISS Incorporate ineligibility Consider “intake” information, including location (may be different than service) such as an “access point”. Collaborate on approach to handling the subtle differences in jurisdictional requirements like licenses and the many various low income support scheme accreditations. Eg In Australia we have NDIS and a national “Health care card”, national “Veterans card”. This all seems like considerations that should be separate objects under one “support” or “entitlement” or similar parent object. Seems distinct (legally) from accreditation though. Include tax number / details for service (to assist in claims, if relevant) Collaborate on including more demographic suitability, eg: Indigenous peoples support (where special programs exist for this) Gender specific services LGBT specific services (or where special support is offered) Age specific services (pre/neo-natal and maternal, youth, aged etc). Consider expanding location as per ISS site (in service) to facilitate end system display Consider adding a dataset objects field Add a last updated field Consider adding more methods to retrieve only components and summary information for services as per HSDA methods Consider electronic referral systems and how they may use this system as a directory. ISS incorporates the concept of a service “endpoint” which holds a list of dictionary items with type of referral and the relevant endpoint. This could expanded to hold all information required to send a referral electronically. Consider interoperability with other directory services.