|Management||Review ANSI Anti-Trust Policy|
DTR IG: http://hl7.org/fhir/us/davinci-dtr/2019May/
Reference Implementation: https://github.com/HL7-DaVinci/dtr
|Reminder: Call Structure & Name Changes|
- Burden Reduction (CRD/DTR/PAS) Implementer Support Call - Wednesday, DTR time slot (11at ET)
- Burden Reduction (CRD/DTR/PAS) Supplemental Examples Call - Friday, PAS time slot (3pm ET)
- Burden Reduction (CRD/DTR/PAS) IG Updates/Future Requirements - call to be scheduled, Mondays at 1pm ET
|HL7 Patient Access API Testing Event - Aug 17-19||2020-08 Patient Access API Testing Event|
|HL7 FHIR Connectathon - Sept 9-11|
2020-09 Connectathon 25
2020-09 Da Vinci CRD / DTR / PAS
- Kick-off planned for next week once we have more details regarding the tool being used during the event
|Implementer Questions (CRD/DTR/PAS)|
- Launch parameters
- Submitted change request to CDS Hooks to better expose mechanism (not currently well documented)
- When you pass back CARD intended to launch SMART app, mechanism to provide an extra parameter
- Parameter gets communicated to auth service, which then passes it along as part of authentication process to SMART on FHIR app
- JSON can contain anything - app context
- Could include JWT, could include same info that was used to launch the hook, etc.
- CRD spec doesn't specify what needs to be in there because it's specific to the SMART app
- If we have generic SMART apps, what would it need - not payer specific
- Hook service needs to know what the app wants; hook service will be 'tuned' to specific app
- Specific SMART app and generic SMART app would need same thing - define what we want in the apps to test out in Connectathon and get it into spec?
- Need to pass the following info:
- Context passed to CDS endpoint
- Access token/ JWT
- URL to go get data (CQL, Questionnaire)
- Need to create an example of what the above would look like in the JSON/payload
- Payers talking to multiple EHRs with their own capabilities - need to standardize interaction
- Developers of the app and service not communicating necessarily
- Providers could choose to work with 'generic' SMART app that interacts with multiple different payers
- Can't use a CARD to launch a native capability (e.g., application module) with CDS Hooks
- Payer does not necessarily know what SMART app is being launched?
- They have to
- This changes paradigm of 'generic' app
- No ability to pass back CARD that says launch 'some' app and you don't know which one
- Connectathon - need to test:
- Test app launch context components and structure
- Test that we can pass the context, access token, and URL
- Payer CDS service pass back CARD with a URL that 'somehow' indicates specific SMART app OR launch whatever your generic functionality is
- Need to add 'floor' model in the CRD IG
- Need to figure out how to do the app launch - URL translations in EHR?
- When invoking hook service, EHR could declare they have a generic app in advance and provide launch URL for that app
- EHR would need to add custom extension to launch
- Hook service shouldn't care what kind of apps could be launched
- Post Sree's list of questions to Confluence
- Guidance on CQL/ how it is evaluated - can implementer choose not to implement CQL?
- Do we want to leave it to app to decide how to execute/evaluate, or provide more guidance?
- Several approaches:
- EHR might have CQL evaluation engine locally
- Application could have CQL evaluation API or someone could provide the API
- Disasdvantage - network traffic (back and forth between EHR prior to doing the evaluation)
- Good option to have it local to application
- Depending on how CQL is written, could call on other libraries
- App would have to embed all the CQL scripts or access via CQL evaluation engine to other libraries needed to execute
- Data Requirements in FHIR Library resource
- Is this mandatory?
- MITRE RI has defined these Data Requirements - instead of making FHIR calls during evaluation stage, doing it as pre-fetch
- If using CQL service, this will be an issue
- Sreekanth Puram to write up options that we can test
- Generic app would need access to CQL evaluation engine and all the value sets - how to make available?
- Specific apps - evaluation services, libraries, etc. - app would define for itself
- DEQM - CQF Ruler with library - open source code used to build services
- Architected to run on provider side vs. DTR application pointing to evaluation endpoint
- FHIR Questionnaire and CQL Questionnaire done by same group?
- Yes, payer or payer's vendor who defines what goes into Questionnaire
- Alternative paths/delegation
- If you don't have all the info needed at time that DTR was launched, need to 'save' and potentially delegate to someone else to complete
- There is guidance in IG, but implementation is EHR-specific
- Save app context and re-launch SMART app - where does this get saved and how does it get re-launched
- What does app need to pass back to EHR so it knows
- Discuss next week with Larry Decelles
- PAS IG Updates - close to publishing?
- Discuss question re: delegation: saving app context and re-launching SMART app - where does this get saved, how does it get re-launched, and what does app need to pass back to EHR so it knows
- Additional implementer questions
| Adjournment||Adjourned at at 11:58am ET|