This page list all the queries that Child Health Project team wants to discuss with CHWG and decide a path forward.
Date and Decision
At this moment NCDHC uses only a handful of elements from the default FHIR profiles. This gives an option to the implementer to supply more data than originally supported by NCDHC. We want to decide whether we should restrict the data set or leave as it is with some control.
I think we have two options on this:
Option 1: Remove all non-supported elements from the profile. This may introduce strict boundary on the profile and loose re-usability.
Option 2: Use must support flag to indicate what is supported by NCDHC. If the source system supplies more data, then NCDHC will not remove them but will not process them or take any ownership of that additional data. They will remain as-is in the supplied resources.
28-07-2020: It was decided to continue with Must Support flag with providing adequate details to the implementer about the meaning of the flag.
NCDHC uses International Bundle resource to represent FHIR document and search result. Any suggestion to use project specific Bundle profile? if yes, then how would it look like and advantage?
11-08-2020: The group suggested that a Bundle Profile could be useful.This will give a better guidance to the implementer about what to send/expect in a FHIR document supported by NCDHC. Shovan to try modeling a Bundle profile and share with the CHWG in the next meeting
|G3||Which Version of R4 based AU profiles should be used 2.1.0 or current? When is the plan to release R4 AU Device profile?|
Brett Esler suggested to use 'current' version to get advantage of the latest and greatest things happening in Au Base. 'current' version is likely to be published before December which aligns with NCDHC Timeline.
|Reuben Daniels Richard Townley-O'Neill Danielle Tavares-Rixon Brett Esler Blair Thompson, Linda|
Date and Decision
Shall we make effective[x] as mandatory in the profile when there any value[X] provided?
in what situation effective[x] can not be provided (other than historical observations which we are not dealing with in NCDHC)?
Add Invariant to check the existence of effective[x] if the absentReason is not provided
28-07-2020: Shovan to talk to NCDHC CI team for more clinical guidance.
Use of component or hasMember along with dataAbsentReason
Do not allow dataAbsentReason along with component and/or hasMember in the same Observation instance.
28-07-2020: Change Invariant to ask for dataAbsentReason only when neither of value[x], component, hasMember or interpretation is present in the Observation but the observation is sent.
Use closed slice vs open slice in coding
NCDHC recommends to use open slice. The sender SHALL send the code as required in the Observation. However they can send additional codes (local codes). The Hub doesn't guarantee about processing the additional code but will not reject the request.
28-07-2020: Proposal accepted by the group.
What is recommended to use for Observation.category
NCDHC to use ‘procedure’ or ‘exam’ as category (as applicable)
28-07-2020: Not to put Must Support for category. If the implementer sends it, the it stays with the Observation.
There are some Observation profiles under NCDHC which points to http://build.fhir.org/ig/hl7au/au-fhir-childhealth/ValueSet-ncdhc-observation-completion-status-1.html just to record if the Procedure was performed or not.
The main objective of these types of Observations are to capture the Observation.interpretation and comments (if any)
The ValueSet includes the following values:
443938003 - Procedure carried out on subject
416237000 - Procedure not done
439495000 - Counselling declined
Proposal: Remove this valueset and implement the following changes
Observation.value[x] make it valueBoolean to allow true/false
move “Procedure not done” and “Counselling declined” as part of Observation.dataAbsentReason
Ongoing discussion with Internal Terminology SME.
Collaborative internally decided to put the 439495000 - Counselling declined as a data absent reason.
NCDHC Terminology SME suggested to use Procedure Carried Out/ Not Carried Out codes instead of boolean Observation value.
Use of au-practitionerrole to record “Examiner” in Observation instead of current implementation where we are usingau-practitioner
Use of au-practitionerrole to record “Examiner” in Observation. This provide the option to record the Examiner and associated Organisation along with practitioner's role.
28-07-2020: Proposal accepted by the group
Date and Decision
|Composition section: Use entry slicing or list of profile?||Composition.section.entry||At this moment Collaborative profiles are sliced with entry slicing due to lack of tooling support.Any alternative option implemented and benefit realized would be helpful to change the approach|
11-08-2020: CHWG suggested to try alternative option and remove profile=$this.resolve(). This method is non good for fhir validation performance reason. Shovan to try options and keep the group posted
Shovan presented a option paper showing the performance comparison of using profile:$this.resolve() vs
it was noticed ~6% performance benefit of using pattern:$this.resolve().code.coding. Collaborative R4 profile will follow this pattern.