- Forum
- Working Groups
- FHIR® Implementations
- Canadian FHIR Baseline Profiles - Governance Stream Meeting - June 12th, 2-3pm EST
Canadian FHIR Baseline Profiles - Governance Stream Meeting - June 12th, 2-3pm EST
- Lloyd Mckenzie
- Offline
- Posts: 132
Please Log in or Create an account to join the conversation.
- Michael Savage
- Topic Author
- Offline
- Posts: 453
In terms of our wording for the work, throughout the process we've used CA Core and Canadian Baseline pretty much interchangeably. The official name starting out last year was 'Canadian FHIR Baseline Profiles', and I think the transition to saying 'CA Core' is mostly because the former is more of a mouthful, rather than the intended function of the work / output changing at all.
In terms of acquiring a governance umbrella and achieving national consensus, that's what we're working toward. The 'due diligence reviews', aligning to the FHIR Maturity Model, working much more closely with HL7 Canada, all of these are aimed at securing more governance, stakeholder input, and overall authority at a Pan-Canadian level. Sheridan put these aspirations and plans into a great roadmap; it's in a few of our decks but I think it's best to refer to our evolving due diligence review framework deck for it (specifically slide 4):
infocentral.infoway-inforoute.ca/en/resources/docs/hl7/canadian-core-profiles (see CA Core - Maturity Roadmap v0.5 2020-06-12)
Please Log in or Create an account to join the conversation.
- Derek Ritz
- Offline
- Posts: 131
Related to my most recent post, I believed (hopefully not in error) that we would look for a governance umbrella for our work similar to the one our US CORE colleagues enjoyed as they operated under ONC support and oversight. I believed, and believe, that if we wish to succeed in developing a national artefact that we'll need to find a way to achieve a national consensus. Achieving consensus isn't an engineering problem... it is a governance problem. To Jean's point... if we can't do the governance, then the baseline can't be more than some lowest common denominator that then must be augmented and customized before it is 'useful'. On the flipside, if we can exert governance and we can achieve a consensus, then we don't have to put air quotes around the word useful... our artefact will be demonstrably fit-for-purpose and we could reasonably expect it to be spec'd in RFPs across the country. We know this is important to digital health COTS product vendors... and should be important to every jurisdiction's MOH. I hope the door is still open for us to develop this consensus (and to revisit and strengthen the content of our artefact to reflect a common core... if ever we get there).
Lastly... upon re-reading it, I realize that my prior post might have come across as more pithy (with a lisp) than pithy. I'm truly sorry for that and more than a bit embarrassed. I was trying to be tongue-in-cheek and reference a joke video that I posted on the IHE Canada forum last April 1st. Of course... it is entirely likely that most folks on this thread never saw it. (It's here ). Please accept my apologies.
Please Log in or Create an account to join the conversation.
- Sheridan Cook
- Offline
- Posts: 68
dritz wrote: Lastly... Lloyd, when you say that "the objective isn't use-case driven" and that "the objective of the baseline is to define something that is easily achievable by as many systems as possible but is still 'useful'" -whose objective is it, exactly, that we are referring to? Who decided that this was the objective... and how was it decided... and why is 'useful' in air-quotes?
I'd point out that the perspectives that Jean and Lloyd provided are aligned with what was outlined in our project scope and terms of reference for the Canadian FHIR Baseline group.
The vision, scope, and terms of reference were developed (at the recommendation of the governance stream) by first looking at the terms of reference by other baseline and Canadian projects (US Core, Netherlands Core, eHealth Ontario, etc) and then collectively refined over the course of the Governance Calls from June 2019-November 2019. They are available today on the google deck @MichaelSavage created (docs.google.com/presentation/d/1w98EOZh1ZDfyJfF6V6Jav7xyIXQ25NgyJQNZjTGTsuQ/edit#slide=id.p1) and shared throughout the process. We don't have a clean slide yet that walks through this journey but a search of "terms of reference" against the FHIR Implementation Forum will pull up the meeting minutes from those calls.
I know this doesn't satisfy questions of how do we assist vendors in aligning to a "superset" that reflects all Canadian use case and implementation decisions, but it does speak to the process and expectations for the CA Core/Baseline efforts that we collectively developed. I don't think anyone disagrees that work we as a larger community can do to align our implementation guides and identify areas where implementors benefit from use case specific economies of scale (across jurisdictions) is meaningful, but I think it might be fruitful to shift the focus of those conversations from "what the Canadian Baseline isn't" to "Where the right fit for those type of efforts might be".
Please Log in or Create an account to join the conversation.
- Derek Ritz
- Offline
- Posts: 131
"Interoperability is not for dilettantes... it is a governance problem pretending to be a technical problem" -- Derek Ritz
Please Log in or Create an account to join the conversation.
- Lloyd Mckenzie
- Offline
- Posts: 132
We're trying to learn from what we did wrong in the v3 world - and one of the things we did wrong was foist way too much on the implementer community at once. We also didn't provide a mechanism for solutions to evolve in a way that maintained compatibility.
While FHIR allows you to nail everything down super tightly, best practice is to *not* do that. Design by constraint doesn't work. It creates solutions that are too complex, too inflexible and inevitably results in non-implementable silos as each independent constraint prohibits what's done elsewhere. FHIR's preferred approach is a "build up" approach. You start by mandating the things that are common and leave flexibility on everything else. As you get into more specific use-cases, you mandate more. But the resulting solutions for distinct use-cases should (in general) still end up being interoperable.
Yes, the methodology we're following here is different than you're used to. We're defining a platform, not a solution. But that platform will get us much further along.
Please Log in or Create an account to join the conversation.