Stream: Da Vinci
Topic: IG for review
Lloyd McKenzie (Aug 09 2018 at 10:08):
I've completed (mostly) the discussion of CDS Hook customizations as well as the proposed new hooks. The content can be found here:
http://build.fhir.org/ig/HL7/davinci-crd/hooks.html
@Andy Gregorowicz @Isaac Vetter @Kevin Shekleton
Also, if anyone knows how to limit {:toc} depth in markdown, I'll buy you a beer in Baltimore :)
Kevin Shekleton (Aug 09 2018 at 13:30):
Thanks for posting this! This is the type of details I was waiting for -- I'm still reading through it now. What do you think about putting the source for this on GitHub so that feedback can be via GitHub?
Otherwise, I can just post feedback here on this thread. GitHub just makes things waaaay nicer
Andy Gregorowicz (Aug 09 2018 at 14:24):
It is up on GitHub https://github.com/HL7/davinci-crd. The main content is here: https://github.com/HL7/davinci-crd/blob/master/src/pagecontent/hooks.md. @Kevin Shekleton , how would you like to propose changes via GitHub and @Lloyd McKenzie , would you be open to it?
Kevin Shekleton (Aug 09 2018 at 14:25):
Thanks @Andy Gregorowicz!
Kevin Shekleton (Aug 09 2018 at 14:25):
I'll just comment on the document for now (rather than opening issues/PRs)
Andy Gregorowicz (Aug 09 2018 at 14:59):
I'm a little confused on the prefetch example in 1.1.1.4. It seems like it is missing the prefetch token. I would have expected something like:
"prefetch": {
"ins-sr": "ServiceRequest?id={{context.orders.ServiceRequest.id}}&_include=ServiceRequest:insurance"
}
Eric Haas (Aug 09 2018 at 15:56):
markdown kramdown site is here: https://kramdown.gettalong.org/syntax.html
to remove a header from the the page toc use: {:.no_toc}
Lloyd McKenzie (Aug 09 2018 at 15:58):
I'm open to using Github comments, though the intention will be to shut them down and move to gForge/Jira once ballot opens. (And I'm not sure whether 'shutting it down' will mean loss of whatever was posted there.)
Eric Haas (Aug 09 2018 at 15:59):
you can look at any of my Ig for how is done
Lloyd McKenzie (Aug 09 2018 at 15:59):
@Eric Haas What I'd like to do is remove a 'level' of headings from the TOC. I don't want to embed cramdown tags for each header - that'd be a maintenance pain
Eric Haas (Aug 09 2018 at 15:59):
@Lloyd where should I start with the framework for multiple versin that you created?
Lloyd McKenzie (Aug 09 2018 at 16:00):
Haven't created it yet. Prioritized getting this content out instead. That's on my list for the weekend.
Lloyd McKenzie (Aug 09 2018 at 16:02):
@Andy Gregorowicz How you expressed it is how it was in the md file. Jekyll just ate it. I'll have to escape the double-braces somehow. Thanks for pointing out the issue.
Andy Gregorowicz (Aug 09 2018 at 16:03):
@Lloyd McKenzie I'm sure Jekyll was just testing to ensure we are on the same page :-)
Eric Haas (Aug 09 2018 at 16:04):
@lloyd check out how to apply options here: https://kramdown.gettalong.org/options.html
Eric Haas (Aug 09 2018 at 16:08):
@Lloyd McKenzie I think ideally would be in the Jekyll _config.yml file but I never got anything to work in _config.yml . I think the Ig-publisher over-rides it @Grahame Grieve is that what happens?
Eric Haas (Aug 09 2018 at 16:11):
the option is toc_levels
Lloyd McKenzie (Aug 09 2018 at 16:13):
@Andy Gregorowicz fixed
Lloyd McKenzie (Aug 09 2018 at 16:14):
@Eric Haas I'll play with _config.yml tomorrow or Saturday. Today I need to focus on the core changes I promised Grahame I'd do :)
Lloyd McKenzie (Aug 10 2018 at 03:05):
I've updated the IG to reflect @Isaac Vetter's feedback on "additional response capabilities". So I think it's now complete in terms of divergences from "pure" CDS Hooks. I'm now pivoting to work on updates to the core spec I've promised to do. Will get back to the IG late tomorrow or Saturday. (I'm hoping FM interprets 'end of day Friday' as 'before start-of-business Monday' :>)
Lloyd McKenzie (Aug 10 2018 at 03:06):
@Andy Gregorowicz, @Kevin Shekleton @Isaac Vetter , let me know if you see anything that seems inappropriate. Also let me know if the hook proposals look sufficient/appropriate to submit to the CDS Hooks process.
Lloyd McKenzie (Aug 13 2018 at 09:33):
An updated version of the IG is now posted. It should be content-complete for R4. Once we confirm the R4 profiles, we'll create the STU3 profiles. Feedback welcome. http://build.fhir.org/ig/HL7/davinci-crd/index.html
Richard Ettema (Aug 15 2018 at 15:37):
Per the CRD call today, please add download links for the generated validation artifacts - STU3 zips for the validation pack, examples, etc.; R4 zips for the examples, etc. and the validation package.
Robert Dieterle (Aug 16 2018 at 22:40):
Suggested changes to the IG (BTW overall excellent)
1.0.1 change "Process of managing billing against patient insurance is a source of significant complexity and cost in the United States." to "The process of determining individual health insurer coverage requirements for specific services or devices is a complex and costly process in the United States"
change "insurance coverage the patient has" to "patient's insurance coverage
1.1.1.1 FHIR -- change R4 reference to ReferralRequest to ServiceRequest
1.2.1.2 , 1.2.2, 1.2.2.2 add hook for start of encounter
1.2.15.2 should we remove the example containing the claimResponse ? CRD is only indicating that a Prior Authorization is needed.
1.2.6 privacy -- remove references to Direct Certificates -- they are held by intermediaries and are dual use certificates (signing and encryption) and may not be appropriate for TLS.
Change "Payer systems SHALL use information received solely for coverage determination purposes and shall not retain received over the CRD interfaces for any purpose other than audit" to "Payer systems SHALL use information received solely for coverage determination purposes and audit" Rationale: may need to retain information to optimize additional request responses.
1.2.6.1 Change "Some payers may not have legal permission to view patient-identifiable healthcare information (PHI) for coverage requirements discovery purposes." to "Some payers or plans may not need in certain use cases may not have the legal right to receive patient-identifiable healthcare information (PHI) for coverage requirements discovery purposes" Rationale: Some plans have no need to receive PHI to determine the coverage requirements (e.g. Medicate FFS) and the beneficiaries should not need to have PHI sent just to ask a coverage question when it is not necessary.
Lloyd McKenzie (Aug 16 2018 at 23:03):
Thanks Bob!
Robert Dieterle (Aug 17 2018 at 02:14):
Profiles
Patient (de-identified) -- please add back must support for type for address
Patient -- ok
Practitioner -- is it reasonable to add in must support for qualification code (need to know what the provider is licensed / approved to do)
PractitionerRole -- is it reasonable to add in must support for code, specialty, (same as above), location (ref), HCservice (ref)
Organization -- ok
Location -- ok
working on the others now
Robert Dieterle (Aug 17 2018 at 02:29):
encounter -- add must support for diagnoses relevant to this encounter (BTW -- how do we exchange patient diagnoses/problem lists?)
ServiceRequest -- is it reasonable to add must support for reason reference -- condition... sets context for the request
SupplyRequest -- same as ServiceRequest
DeviceRequest -- same as ServiceRequest
MedicationRequest -- same as ServiceRequest
NutritionOrder -- ok
Robert Dieterle (Aug 17 2018 at 02:40):
Coverage -- need non-PHI version -- only need status, type, payor, plan (class type=plan), period
Medication -- add must support for status
Device -- must support Device Identifier but cannot require -- relax cardinality on UDI Carrier and DI to 0..1
Lloyd McKenzie (Aug 17 2018 at 02:41):
Patient diagnoses/problems would generally be Condition.
Lloyd McKenzie (Aug 17 2018 at 02:41):
Why do you care about Medication.status - that's about it's position in the formulary - it has nothing to do with the patient.
Robert Dieterle (Aug 17 2018 at 02:49):
Can we add must support for Condition? -- isn't observation relevant?
Medication.status -- you are correct -- was looking for a med list and status (active, new, discontinued, …) where is that?
Lloyd McKenzie (Aug 17 2018 at 02:52):
Neither the Conditions nor Observations that are likely to be of interest will necessarily be linked from the data we're getting back - the payer will need to query for those. Support for Observation, Condition, etc. will be part of USCore and inherited by default in the R3 guide. Do we need to replicate all of USCore in R4 for CRD?
Robert Dieterle (Aug 17 2018 at 03:04):
Appointment -- can we add must support for Indication (condition) and service category (need to know type of facility for the appointment
Communication Request -- ok
Questionnaire Task -- ok
Need to have support for Condition at a minimum and most likely Observation -- Is there a reason we should query when the condition is almost universally needed to make coverage decisions?
Not trying to replicate all of USCore, only thing we know we need
Lloyd McKenzie (Aug 17 2018 at 03:29):
We can potentially get the Condition that's the reason. But if comorbidities are relevant, those won't typically be linked to the order. Nor will recent lab values or other information that may influence decisions. We'll do our best to add Condition and Observation.
Robert Dieterle (Aug 17 2018 at 03:31):
Thank you -- going off line -- if you need something urgent please text me
Lloyd McKenzie (Aug 18 2018 at 08:30):
Ok, the "final" version is now posted - should have all agreed changes. Jean may have time to make last minute corrections tomorrow evening before the final-final deadline tomorrow midnight. (I'm offline for 45days starting now.) So if you have time to review, get your feedback in ASAP.
@Andy Gregorowicz, I changed a couple of hook names and parameter names to better align with existing naming conventions. Wanted to give you a heads up in case you'd already coded the old ones.
http://build.fhir.org/ig/HL7/davinci-crd
Grahame Grieve (Aug 18 2018 at 09:20):
I'm offline for 45days starting now
This counts as one of the more significant typos in Zulip so far. I believe Lloyd means 4-5 days. but perhaps it's a realllllllly long camp, this one....
Lloyd McKenzie (Aug 18 2018 at 15:50):
Depends on how the compass work goes I guess... :)
Last updated: Apr 12 2022 at 19:14 UTC
