Faites-nous part de vos impressions sur le Serveur terminologique, et aidez-nous à améliorer nos services! Vous avez jusqu’au 3 décembre 2024 pour répondre au sondage. Votre avis nous intéresse! En savoir plus >

Partager :

file Canadian FHIR Baseline Profiles - Profiling Stream Meeting - September 13th, 2-3pm EST

  • Messages : 68
il y a 5 ans 2 mois #5314 par Shamil Nizamov
I'd like to bring a topic to discuss - which way is most feasible related to the extensions structure: flat structure or complex extensions.

E.g., I'm working on the Ethnicity extension as one of requirements in BC, which contains the ethnicity code itself and who reported it. Thus, there are two extensions and I may group them in the way similar to US Core Ethnicity extension. Now, if the Patient resource instance contains only an extension with the ethnicity code, a developer has to iterate over all extensions, find out the one related to ethnicity and then iterate all over again to grab the actual code, instead of getting it in the first run. The same is with Aboriginal extensions, there are four of them.
Is there any rationale for making developers life harder than it could be?

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 454
il y a 5 ans 2 mois #5308 par Michael Savage
Attendees

Michael Savage
Sheridan Cook
Russ Buchanan
Ken Sinn
Fariba Behzadi
Igor Sirkovich
Jorge Pichardo
Shamil Nizamov
Mini Riar

Updates

• FHIR North: Will not be moving forward with plans to conduct connectathon-style testing at FHIR North this year; too premature given we are just now getting into the more clinical profiles, and as such there have not been suggestions for use cases to use as drivers for testing at this time
• Pacing and Prioritization of Review of Profiles: will look to adjust the timelines to give more time for each review period & can re-arrange so there are not as many profiles in each ‘batch’
• Will continue with the sequence of profiles as drafted, but Community members are encouraged to post if they are working with specific profiles that they would like to review sooner rather than later
• ACTION ITEM: Community to either post to the forum or email separately (Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.) for requests to review profiles sooner than their current position in the sequence of profiles to review
• ACTION ITEM: Request to review proposed extensions for Patient profile (Items #64-67) in GitHub Issue Log
• Community is encouraged to gather feedback on profiles offline from other key stakeholders (Vendors, clinical SMEs, etc.); feedback is not limited to the profiling calls, and not limited to just Community attendees
• For items reviewed on Profiling Calls, the items which cannot be actioned from the call’s discussion (i.e. we decide we don’t have enough information to come to an informed decision), will add a ‘deferred/unresolved’ tag to the item in the GitHub log, so it is understood to require further insight at a later time
• Key Points raised on future governance of this work (i.e. who will endorse and support the work beyond the current community-review stage of work): Community encouraged to engage on the relevant post on the Forum, and attend the next governance stream call where it will be a featured discussion item

Profiling Discussion Items

• #63: Medication_Ingredient_itemCodeableConcept (Unresolved)
o Needs to be able to include terminology / value sets that go beyond just e-prescribing use cases
o Two actions recommended: make sure the binding is extensible; engage with folks involved in CCDD work (Bev Knight) to get guidance on binding, approach to building a more comprehensive set < Igor volunteered to action

• #62: Medication_Code_Text (Closed)
o about string length and mandatory (1:1). Proposal to remove string length, change to optional element (0:1). No opposition to proposal, decision to implement change.
o (Leave as MustSupport).

• #61: Medication_Ingredient (Closed)
o DHDR doesn't support ingredients - example of a use case where it wasn't needed. Ken: MustSupport puts onus on clients to store an ingredient received. Should be determined for each use case and probably not a requirement. Decision to implement change pending new information from discussion about CCDD

• #60: Medication_Code (Unresolved)
o Similar to issue #63 , action carried forward
o Two actions recommended: make sure the binding is extensible; engage with folks involved in CCDD work (Bev Knight) to get guidance on binding, approach to building a more comprehensive set < Igor volunteered to action

• #68: Medication_Extensions (Unresolved)
o Opened up broader question of the use of extensions in Canadian Core – are they Must Support or Optional?
o One of the key things is to ensure implementers aren’t just making up their own project-specific extensions – we can at least point implementers to optional extensions
o Recommendation to revise Canadian Core project wording on use of extensions – can look to US Core, IPS, SDC guides for inspiration

• #45: Device_Binding_deviceName.type (Unresolved)
o Not discussed in call

• #44: Device_Binding_property.type (Unresolved)
o Not discussed in call

• ACTION ITEM: Community to email Mike (Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.) if interested in authoring their proposed changes directly into project (once approved during discussion)
• ACTION ITEM: If posting proposed changes to GitHub directly (as opposed to sending templated proposed changes to Mike), please email Mike briefly just to notify that new issues are posted

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 454
il y a 5 ans 2 mois #5284 par Michael Savage
Hi all,

The draft agenda for this Friday's Profiling Call is as follows (note that, due to the purpose of the call being to review profiling items, the first 5 items will be fielded relatively quickly to allow for as much time as possible available for profiling discussion):

1. Shelving connectathon plans for short-term (i.e. FHIR North) in favour of getting reviews and Canadian contexts into the remaining draft Profiles
2. Pacing of Profile Review Timelines and options for re-prioritization of profiles to be reviewed
3. Online & Offline Feedback
4. Decisions - use of 'unresolved' / 'deferred' tags on sticky items
5. Discussion items raised on governance going forward - opportunities for forum / offline discussion prior to next governance call
6. Profiling Discussion Items - Medication and Device Proposed Changes from GitHub list - github.com/scratch-fhir-profiles/CA-Core/issues
*Igor - a heads-up, if you can identify for us the broad context(s) in which you've proposed your Medication proposals that would be great*

Thank you!

-Mike

Connexion ou Créer un compte pour participer à la conversation.

Logo d'InfoCentral

La santé numérique à votre service

 

Transformer les soins de santé au Canada grâce aux technologies de l'information sur la santé.