# fhir.chat digest - August 2021
# fhirvalidator.org
Interactive tool for validation

Nice playground for validation - we can do the same for zen
## Clarification on `url` search parameter
[chat](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Clarification.20on.20.60url.60.20search.20parameter)
https://build.fhir.org/search.html#uri contains a section on uri parameters that says:
> Note that for uri parameters that refer to the Canonical URLs of the conformance and knowledge resources (e.g. StructureDefinition, ValueSet, PlanDefinition etc), servers SHOULD support searching by canonical references, and SHOULD support automatically detecting a |[version] portion as part of the search parameter, and interpreting that portion as a search on the version.
I think that is saying that servers should automatically handle ValueSet?url=http://acme.org/fhir/ValueSet/123%7C1.0.0 the same as ValueSet?url=http://acme.org/fhir/ValueSet/123&version=1.0.0.
Am I interpreting the spec right?
Why recommend this special behavior for this one search parameter or type uri and is there anything in their SearchParameter definitions to indicate their special-ness?
---
Aidbox:
* [feature] Support for search by cannonical
Think about cannonical at all - how do we handle it in Aidbox
## Enrollment
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Enrollment)
tags: [modeling]
> When designing provider edge application workflows, a common mental model is "Enrollment" -> "Supplementation" -> "Writeback"
>Enrollment is the moment at which an app knows there is work to be done for a given patient. For example, for a surgical application, this might be the moment that a patient is scheduled for a case. For a diagnostic testing application, it could be the moment that a provider places an order for the test. In any circumstance, this is the first time that you know of the patient and your trigger to do something with their data.
>Enrollment in an pre-FHIR world was primarily driven off of HL7v2 ADT, ORMs and SIU, with the occasional single sign-on launch passing patient ID via SAML or encrypted URL.
>Enrollment is different with FHIR. SSO is encapsulated well with SMART, but the query-based nature of FHIR (at least the capabilities we see on the market) doesn't lend itself to the ideal enrollment scenario. FHIR subscriptions are undeveloped and not seen with EHRs yet, polling is inefficient and often not widely supported (I can't hit most EHRs' ProcedureRequest endpoints to get the newest updates; I need to pass patient or encounter as a required parameter), and no one seems to like messaging.
>So applications are forced to develop clunky flows where providers have to select patients in the application, it seems. How are people thinking about / solving for this?
> Following...we had a similar need. I'd raised it with the task group- [chat](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Existing.20valuesets.20for.20Patient.20Portal.20enrollment.20status). We went ahead and used the EnrollmentRequest/Response to implement it- even though it's a stub state. I know- we probably broke a few rules here, but it fit our use case really well! In DSTU2, this resource was more generic.
## FHIR Async for CRUDS Interactions & Operations
by Josh Mandel
> Today, FHIR's async support is geared toward the "data export" use case, where processing is async because a server needs to sift/collate large piles of data.
> Do folks have other use cases for async?
> I'm especially interested in cases where you might not have huge piles of data (in or out), but where processing might be async for other reasons (architectural decisions like work queue-driven processing, out-of-band review, etc). Use cases where you might want to asynchronously handle an individual CRUD request?
Josh started discussion for async interactions with FHIR server and described a proposal [here](https://hackmd.io/@jmandel/fhir-async-cruds)
The general idea is to introduce async mode for most of FHIR operations.
## References in national profiles
tags: [Profiles National Norway]
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/References.20in.20national.20profiles)
Norway work on Profiles
## Patch for Collections
tags: [API PATCH]
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.E2.9C.94.20Patch.20for.20adding.20to.20collection)
Collections like List looks like an **anti pattern** - it can be decomplected if introduce ListItem resource
## UCUM Valueset
tags: [Terminology]
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.E2.9C.94.20Patch.20for.20adding.20to.20collection)
UCUM is more engine than terminology
## Bulk Operation Problems [API Bulk]
error reporting
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.E2.9C.94.20Patch.20for.20adding.20to.20collection)
## Complex Types
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Handling.20complex.20types.20in.20inter-version.20extensions)
> Lloyd McKenzie1:16 AM
> In R4 of the core spec here, we say
>Where complex data types have no equivalent in an earlier version, use a complex extension, containing extensions also following this pattern. Follow the same pattern for any elements not found in data types in earlier versions
However, we don't explain how that works in practice in a few ways:
> how does the data type being represented get exposed?
what are the URLs for the complex extension?
what happens if the element in question is a choice - between types that are part of the version the extension is referencing and types that aren't? E.g. what is the name of the value[x] when the type isn't a supported type?
These questions come from FHIR#31721 from @Chris Moesel. We don't (yet) have good answers and are seeking ideas.
## How to segregate resources for different Line of Buissness
tags: [FHIR-first FAQ]
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Partitioning.20by.20line-of-business)
> Team: I have a use case in hand and need some suggestions. Lets say we are getting Data from 5 Different LOB's and we are ingesting them to Azure FHIR.
How can we segregate these Line of Business in FHIR when we query them back from an app
Lloyd Response:
> There are a few options:
> * expose different endpoints for each LOB
> * ensure each user authenticates and is tied to a single LOB and then > auto-filter based on what the user can access
> * expose the LOB in Resource.meta.source and then filter by _source as needed
I is quite common question, we can write post how to do it in aidbox
## Bulk Import
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/bulk.20data.20import)
Checkout Tool FHIRLoader by Microsoft (https://github.com/microsoft/fhir-loader)
Can we reuse MS Loader or we need an Aidbox loader???
## FHIR first architecture
[discussion](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/FHIR.20Server.20Architecture.20Best.20Practices.20.28System.20of.20Record.29)
> Hello Everyone, The company I work for is in the progress of doing R & D on building our own EHR Application and we are definitely considering have a FHIR component. My question to everyone is: When designing modern healthcare applications, do we make the FHIR Server the system of record? Especially, if you are starting from scratch. (or) Do you have your own internal app/database and do a lot of triggers/subscriptions back and forth to keep both systems up to date.