Page tree
IDSummaryDetailsPriorityAssigneeSubmitted BySection numberStatusGroupScheduleChange TypeHTML Page(s)ResolutionPre-applied?Ballot-weightTarget releaseBallotCategoryReviewing Work GroupIn-Person?Waiting for Input e-mail(s)Retract/WithdrawSpecificationReal SubmitterResource(s)Ballot ResolutionOpen DateClose DateLast Modified Date
22152Suggest to add RECOMMENDED and OPTIONAL. - CRD #1  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) --- Comment: Suggest to add RECOMMENDED and OPTIONAL. --- Summary: Suggest to add RECOMMENDED and OPTIONAL.3Nonefhir_bot4.1.2 ConventionsTriagedReady-For-VoteNoneNone(profiles)<p>We use the same conformance terms as are used in the FHIR core specification and as are conventionally used in other HL7 specifications.  "recommended" corresponds to SHOULD and 'optional' would typically correspond to MAY.</p>NoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22156I assume the configuration options can be selected by the EMR in a service configuration menu? - CRD #5  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: The extension here will be called davinci-crd.configuration-options. It will be a configuration object that will contain an array of available options. Each option will include four mandatory elements: --- Comment: I assume the configuration options can be selected by the EMR in a service configuration menu? The text seams to suggest this but this should be clarified further. --- Summary: I assume the configuration options can be selected by the EMR in a service configuration menu?3Nonefhir_bot4.2.1.2.1 ConfiguratTriagedReady-For-VoteNoneNone(profiles)<p>Will clarify that the expectation is that the EMR SHOULD expose the configuration options and allow specifying values</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtYesNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive5/13/20195/13/2019
22157will -> Shall - CRD #6  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Each option will include four mandatory elements: Proposed Wording: Each option SHALL  include four mandatory elements: --- Summary: will -> Shall3Nonefhir_bot4.2.1.2.1 ConfiguratTriagedReady-For-VoteNoneNone(profiles)NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive5/13/20195/13/2019
22158Add a default value for each option. - CRD #7  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: It will be a configuration object that will contain an array of available options. Each option will include four mandatory elements: --- Comment: Add a default value for each option. --- Summary: Add a default value for each option.3Nonefhir_bot4.2.1.2.1 ConfiguratTriagedReady-For-VoteNoneNone(profiles)<p>Will add an 'optional' default element to make visible to the user what the default will be if they don't specify an override.</p>NoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive with Mod5/13/20195/13/2019
22159Make configuration options a SHOULD - CRD #8  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: When invoking a hook, the client system can convey any supported configuration options as part of the invocation of the hook. This will be done using the davinci-crd.configuration extension Proposed Wording: When invoking a hook, the client system SHOULD convey any supported configuration options as part of the invocation of the hook. This will be done using the davinci-crd.configuration extension --- Summary: Make configuration options a SHOULD3Nonefhir_bot4.2.1.2.2 Hook confiTriagedReady-For-VoteNoneNone(profiles)<p>Will clarify that support for configuration options is *optional* on both client and server sides, however if systems choose to support the configuration capability, then they SHALL send any configured configuration information on each hook invocation and SHALL respect passed configuration information when received.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive with Mod5/13/20195/20/2019
22160SHALL be optional equals to SHOULD/RECOMMENDED - CRD #9  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: &bull; Inclusion of configuration information in a hook call SHALL be optional (i.e. no hook invocation is permitted to fail because configuration information was not included). Proposed Wording: &bull; Inclusion of configuration information in a hook call ís RECOMMENDED (i.e. no hook invocation is permitted to fail because configuration information was not included). --- Comment: SHALL be optional equals to SHOULD/RECOMMENDED --- Summary: SHALL be optional equals to SHOULD/RECOMMENDED3Nonefhir_bot4.2.1.2.2 Hook confiTriagedReady-For-VoteNoneNone(profiles)<p>Reword to: "CDS Servers SHALL NOT require the inclusion of configuration information in a hook call  (i.e. no hook invocation is permitted to fail because configuration information was not included)."</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive with Mod5/13/20195/13/2019
22161Client or CDS Server? - CRD #10  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Note: Recognizing these tokens doesn&rsquo;t mean the client must support prefetch or the requested prefetch query, only that it recognizes the token, doesn&rsquo;t treat it as an error and - if it supports the query - substitutes the token correctly. --- Comment: Client or CDS Server? --- Summary: Client or CDS Server?3Nonefhir_bot4.2.1.3 Additional PTriagedReady-For-VoteNoneNone(profiles)<p>It's referring to the CDS Client - the one that's invoking the hook and potentially performing the pre-fetch queries.  A service identifying desired prefetches doesn't obligate the client (e.g. EHR) to providing those.</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneConsidered - Question Answered5/13/20195/13/2019
22162instantiatesCanonical -> instantiatesUri - CRD #11  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: resource": {         "resourceType": "Task",         "instantiatesCanonical": "http://example.org/Questionnaire/XYZ|2",         "basedOn": "MedicationRequest/5"         "status": "ready", Proposed Wording: resource": {         "resourceType": "Task",         "instantiatesUri": "http://example.org/Questionnaire/XYZ|2",         "basedOn": "MedicationRequest/5"         "status": "ready", --- Summary: instantiatesCanonical -> instantiatesUri3Nonefhir_bot4.2.1.4.1 if-none-exTriagedReady-For-VoteNoneNone(profiles)<p>This is a formal reference to a resource by its cannonical URL and therefore instantiatesCanonical is the correct element to use.  (instantiatesUri would be for pointing to a PDF or web page or something like that.)</p>NoneAffirmativeNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22163is already covered by the transaction processing rules. Can be removed. - CRD #12  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) --- Comment: is already covered by the transaction processing rules. Can be removed. --- Summary: is already covered by the transaction processing rules. Can be removed.3Nonefhir_bot4.2.1.4.2 Linkage beTriagedReady-For-VoteNoneNone(profiles)<p>The results coming back from a hook are not a FHIR Transaction - and thus those rules don't automatically apply.  This specification therefore needs to specify the rules (though it does align with the FHIR rules for a Transaction Bundle.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22164Be consistent with terms - CRD #13  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) --- Comment: Systems, clients, payers, servers, EMR systems, &hellip; multiple expressions are used. In CDSHooks there is the EMR, a CDS Server and the CDS. Please define what each of these terms means and how they map on the CDS Hooks terminology and use them consistently. --- Summary: Be consistent with terms3Nonefhir_bot4.2.2 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>Will use the term 'Client' and 'Server' when referring to systems.</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtYesNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive5/13/20195/13/2019
22165Why require that they support at least one of the new ones? Isn’t that up to the CDS? - CRD #14  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: book. Client systems conforming to this implementation guide SHALL support at least one of the hooks listed below and SHOULD support all that apply to the context of their system. Proposed Wording: book. Client systems conforming to this implementation guide SHOULD support at least one of the hooks listed below and SHOULD support all that apply to the context of their system. --- Comment: Why require that they support at least one of the new ones? Isn&rsquo;t that up to the CDS? --- Summary: Why require that they support at least one of the new ones? Isn&rsquo;t that up to the CDS?3Nonefhir_bot4.2.2 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>If the client system doesn't support at least one, then it's not doing anything covered by the IG and has no right to claim conformance to the IG.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22166There is no to use SHOULD here as this is a implementation suggestion and not a requirement for interoperability. - CRD #15  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: book. Client systems conforming to this implementation guide SHALL support at least one of the hooks listed below and SHOULD support all that apply to the context of their system. Proposed Wording: book. Client systems conforming to this implementation guide SHALL support at least one of the hooks listed below and should support all that apply to the context of their system. --- Comment: There is no to use SHOULD here as this is a implementation suggestion and not a requirement for interoperability. --- Summary: There is no to use SHOULD here as this is a implementation suggestion and not a requirement for interoperability.3Nonefhir_bot4.2.2 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>SHOULD statements are never firm 'requirements'.  They are recommendations about appropriate behavior to maximize interoperability.  Supporting all relevant hooks will maximize interoperability between EHR and Payers and thus is an appropriate statement to make</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22167duplicate - remove - CRD #16  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: For example, a payer that only provides drug coverage would never have coverage information to return on an encounter-discharge event. Payer systems conforming to this implementation guide SHALL provide a service for at least one of the hook types listed below and SHOULD support all hooks relevant to the types of coverage they provide. --- Comment: duplicate - remove --- Summary: duplicate - remove3Nonefhir_bot4.2.2 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>The previous set of statements was with respect to clients.  This is with respect to servers.  Both sets of statements are needed</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22168MAY does not make sense. - CRD #17  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Clients and payers MAY choose to support additional hooks that are relevant to Coverage Requirements Discovery as well - both hooks appearing in the registry on the CDS Hooks website and custom hooks defined elsewhere. --- Comment: MAY does not make sense. The CDS service will support all hooks that it requires. The EMR must do so as well. What happens when the CDS Server does not? Is there some way to detect this? Is the CDS service not not required to deal with the situation where it does not? suggest to make it lower case. --- Summary: MAY does not make sense.3Nonefhir_bot4.2.2 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>The purpose of this statement is to make clear that the CRD implementation guide isn't intended to limit either clients or servers from supporting additional hooks.  Obviously interoperability would only occur in those situations where clients and servers happen to support the same ones.  However, they can coordinate to achieve that end.  Such collaborations might lead to proposals to add additional hooks in the future</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22169Maybe defining a ‘profile’ for each of these cases would be a good idea. - CRD #18  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) --- Comment: It all depends on where the services are hosted. For local services this is not required as they can access the CDR. For remote services this is essential as otherwise they cannot operate. Maybe defining a &lsquo;profile&rsquo; for each of these cases would be a good idea. --- Summary: Maybe defining a &lsquo;profile&rsquo; for each of these cases would be a good idea.3Nonefhir_bot4.2.4 PrefetchTriagedReady-For-VoteNoneNone(profiles)<p>Remote vs. local has no influence on accessibility.  CDS-Hooks allows remote servers to query the client's (i.e. EHR's) server.  As well, we expect all payer CDS servers will be remote from the EHRs, so dual profiles are unnecessary.</p>NoneAffirmativeNone2019 May CRDCommentFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22170Are these suggestions intentional informational? I would expect that most may’s and should’s should be uppercase - CRD #19  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) --- Comment: Are these suggestions intentional informational? I would expect that most may&rsquo;s and should&rsquo;s should be uppercase --- Summary: Are these suggestions intentional informational? I would expect that most may&rsquo;s and should&rsquo;s should be uppercase3Nonefhir_bot4.2.3 General guidanTriagedReady-For-VoteNoneNone(profiles)<p>Will go through and search for all "should", "shall" and "may" and replace them either with SHOULD, SHALL or MAY or alternative words that leave no confusion - based on the degree of conformance intention.</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive5/13/20195/13/2019
22171Are these formal card types, like profiles? - CRD #20  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Of the card types here, conformant client systems SHALL support the External reference and Instructions responses. They SHOULD support the remainder. Payer servers SHALL support at least one of these response type and MAY support as many as necessary to convey the requirements of the types of coverage they support. --- Comment: This is confusing. Are these formal card types, like profiles? In this case, the sub-sections should require something. and a more strict specification format may be required.  Otherwise state the CDS-Hooks spec elements that are required. --- Summary: Are these formal card types, like profiles?3Nonefhir_bot4.2.3.2 Potential CRTriagedReady-For-VoteNoneNone(profiles)<p>Change from "card types" to "response types" and at the beginning of the section that the "response types" are not formally identified in the cards, but instead reflect CRD-specific profiles on the cards that describe CRD-expected behavior.</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNonePersuasive5/13/20195/13/2019
22172May other formats also be supported? - CRD #21  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Of the card types here, conformant client systems SHALL support the External reference and Instructions responses. They SHOULD support the remainder. Payer servers SHALL support at least one of these response type and MAY support as many as necessary to convey the requirements of the types of coverage they support. --- Comment: May other formats also be supported? --- Summary: May other formats also be supported?3Nonefhir_bot4.2.3.2 Potential CRTriagedReady-For-VoteNoneNone(profiles)<p>The specification already says that other card types either SHOULD or MAY be supported (depending on client or server and whether described in CRD or not).  Content not supported by CDS Hooks is outside the scope of this specification.</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22174It could also be a contained resource in the Task. - CRD #23  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: This suggestion will always include a &ldquo;create&rdquo; action for the Task. The Task will point to the questionnaire to be completed using the Task.input property with a Task.input.name of &ldquo;questionnaire&rdquo;. That Questionnaire might be included with a separate conditional &ldquo;create&rdquo; action or might be excluded with the presumption it will already be available or retrievable by the client via its canonical URL from the original source or from a local registry. The Task.code will always include the CRD-specific complete-questionnaire code. The reason for completion will be conveyed in Task.reasonCode. --- Comment: It could also be a contained resource in the Task. --- Summary: It could also be a contained resource in the Task.3Nonefhir_bot4.2.3.2.5 Request foTriagedReady-For-VoteNoneNone(profiles)<p>Contained resources are only used if they are only relevant in the context of the containing resource.  We don't expect there to be any Questionnaires that are specific to a single patient order, so containment would not be appropriate.  (Containment is never to be used as just a convenient transport mechanism.)</p>NoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22175A suggestion to fill in questionnaire could also be signalled using a ServiceRequest with a servicerequest-questionnaireRequest extension? Why use a Task instead? - CRD #24  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: This suggestion will always include a &ldquo;create&rdquo; action for the Task. The Task will point to the questionnaire to be completed using the Task.input property with a Task.input.name of &ldquo;questionnaire&rdquo;. That Questionnaire might be included with a separate conditional &ldquo;create&rdquo; action or might be excluded with the presumption it will already be available or retrievable by the client via its canonical URL from the original source or from a local registry. The Task.code will always include the CRD-specific complete-questionnaire code. The reason for completion will be conveyed in Task.reasonCode. --- Comment: A suggestion to fill in  questionnaire could also be signalled using a ServiceRequest with a servicerequest-questionnaireRequest  extension? Why use a Task instead? --- Summary: A suggestion to fill in questionnaire could also be signalled using a ServiceRequest with a servicerequest-questionnaireRequest extension? Why use a Task instead?3Nonefhir_bot4.2.3.2.5 Request foTriagedReady-For-VoteNoneNone(profiles)<p>Task is the preferred way of capturing and tracking "to do" items.  ServiceRequest (as all requests) represents an 'authorization' and doesn't necessarily represent something that is immediately actionable.</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneConsidered - Question Answered5/13/20195/13/2019
22178I do not think that HL7 should provde requirements on software engineers. Remove SHALL. - CRD #27  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: . Implementers SHALL be familiar with and adhere to any security and privacy rules defined by: Proposed Wording: . Implementers should be familiar with and adhere to any security and privacy rules defined by: --- Comment: I do not think that HL7 should provde requirements on software engineers. Remove SHALL. --- Summary: I do not think that HL7 should provde requirements on software engineers. Remove SHALL.3Nonefhir_bot4.4 Privacy, SercuriTriagedReady-For-VoteNoneNone(profiles)<p>It's quite common for IGs to assert security expectations on systems.  The whole point of IGs is to set expectations for implementation.  However, we can reword to "Implementions SHALL adhere to" to avoid a possible perception of limiting implementers to only those who are already familiar with.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive with Mod5/13/20195/13/2019
22180Basically you have to provide de-indentifiable data? If so, then I suggest stating this. - CRD #29  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: &bull; Client systems SHALL ensure that the resource identifiers exposed over the CRD interface are distinct from and have no determinable relationship with any business identifiers associated with those records. E.g. the Patient.id element cannot be the same as or contain in some fashion a patient&rsquo;s social security number or medical record number. --- Comment: Basically you have to provide de-indentifiable data? If so, then I suggest stating this. --- Summary: Basically you have to provide de-indentifiable data? If so, then I suggest stating this.3Nonefhir_bot4.4 Privacy, SercuriTriagedReady-For-VoteNoneNone(profiles)<p>This is not a general de-identifiable data requirement.  It's simply imposing a constraint that the resource id not expose personally identifying information.</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22181It seams to be to strict to require this also for EMR's that do not work with such payers. - CRD #30  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Some payers may not have legal permission to view patient-identifiable healthcare information (PHI) for coverage requirements discovery purposes. EMR systems SHALL support filtering exposed FHIR resources to be a non-PHI &ldquo;redacted&rdquo; view. This view SHALL ensure that all resources exposed through the CDS Hooks and SMART on FHIR interfaces are filtered as follows: --- Comment: It seams to be to strict to require this also for EMR's that do not work with such payers. Is SHALL really required? Suggest to remove SHALL. --- Summary: It seams to be to strict to require this also for EMR's that do not work with such payers.3Nonefhir_bot4.4.1 Non-PHI Hook ITriagedReady-For-VoteNoneNone(profiles)<p>EMRs are free to not comply with this IG (though their customers may have some problems getting paid by CMS in the future).  But if they conform with this IG, then the expectation is that they SHALL have this behavior.  It's a US industry requirement.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive5/13/20195/13/2019
22182Is this something that needs to be signalled in the CDS Service definition? - CRD #31  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: Client systems SHALL determine whether a payer system should receive the PHI or non-PHI version of the CRD interface at the time the payer is configured to have access to their system. --- Comment: Is this something that needs to be signalled in the CDS Service definition? --- Summary: Is this something that needs to be signalled in the CDS Service definition?3Nonefhir_bot4.4.1 Non-PHI Hook ITriagedReady-For-VoteNoneNone(profiles)<p><br /> This is intended to be established at the time the payer CDS is configured and not as part of the CDS Service definition.  Will add additional clarifying language.</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneNot Persuasive with Mod5/13/20196/24/2019
22183This seams to be in contrast with earlier stantements on the reduction of the number of cards. - CRD #32  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: 1. Practitioners will rely on the information provided by the Coverage Requirements Discovery process to determine if there are any special steps they need to take such as requesting prior authorization. As a result, it&rsquo;s important to them to know definitively whether requirements exist or not. While potentially noisy, payers SHALL provide a message that says &ldquo;No coverage requirements for [ABC]&rdquo; if it is definitively known that there are no requirements for the proposed action or &ldquo;Unable to determine coverage requirements for [ABC] - please review [XYZ]&rdquo; or some equivalent when processing errors (e.g. unrecognized service code) prevent the payer from determining coverage requirements. --- Comment: This seams to be in contrast with earlier stantements on the reduction of the number of cards. What is the required/advised communication approach? Is it wise to include a separate section where this is explained together? --- Summary: This seams to be in contrast with earlier stantements on the reduction of the number of cards.3Nonefhir_bot4.5 Additional ConsiTriagedReady-For-VoteNoneNone(profiles)<p>This is considered to be essential information for clinicians to have.  If they have no information about whether there are requirements, then they're going to make phone calls or otherwise investigate whether there are rules, so being told "no rules" results in saved time and is not considered "noise".</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneConsidered - Question Answered5/13/20195/13/2019
22184Is this the audit-purpose mentioned earlier in this spec? - CRD #33  Submitted by: Bas van den Heuvel  (Philips) On behalf of:  (bas.van.den.heuvel@philips.com) Existing Wording: . Therefore, in addition to any logging performed for security purposes both clients and servers SHALL retain logs of all CRD-related hook invocations and their responses that can be accessed in the event of a dispute by authorized personnel. As well, all Card.suggestion elements SHALL populate the Suggestion.uuid element to aid in logging. --- Comment: Is this the audit-purpose mentioned earlier in this spec? --- Summary: Is this the audit-purpose mentioned earlier in this spec?3Nonefhir_bot4.5 Additional ConsiTriagedReady-For-VoteNoneNone(profiles)<p>Auditing is mentioned several times in the IG</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDBas van den HeuvelNoneConsidered - Question Answered5/13/20195/13/2019
22191Clarify semantics of encounter-start with regard to transition from ED to hospital floor. - CRD #40  Submitted by: Kensaku Kawamoto  (University of Utah) On behalf of:  (kensaku.kawamoto@utah.edu) --- Comment: For encounter-start, need to clarify what the expectations is for the external to facility -> ED -> inpatient transition.  E.g., is transitioning from ED to inpatient considered a separate encounter-start event?  The term "patient is admitted" would seem to indicate it's the ED -> inpatient transtiion, not when the patient first arrived at ED.  Should clarify. --- Summary: Clarify semantics of encounter-start with regard to transition from ED to hospital floor.3Nonefhir_botTriagedReady-For-VoteNoneNone(profiles)<p>It's not within our scope to try to standardize hospital administrative practices.  Encounter boundaries are determined by business practice, not by FHIR.  The CDS Hooks will trigger based on where they fit into the EHR workflow.  When users choose to invoke particular points of the workflow is not within our control.</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDKensaku KawamotoNoneNot Persuasive5/13/20195/13/2019
22192How are trigger guards expected to be implemented? - CRD #41  Submitted by: Kensaku Kawamoto  (University of Utah) On behalf of:  (kensaku.kawamoto@utah.edu) --- Comment: Suggest discussion on how Hooks trigger guards are expected to be handled to restrict when the hooks are being invoked. --- Summary: How are trigger guards expected to be implemented?3Nonefhir_botTriagedReady-For-VoteNoneNone(profiles)<p>The IG doesn't refer to trigger guards and they don't yet exist.  This is something that can be raised against the CDS Hooks specification</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDKensaku KawamotoNoneNot Related5/13/20195/13/2019
22194What is the role of intermediary services? - CRD #43  Submitted by: Kensaku Kawamoto  (University of Utah) On behalf of:  (kensaku.kawamoto@utah.edu) --- Comment: Recommend greater discussion on the potential role of intermediaries, such as a service that handles requests to different insurance providers. --- Summary: What is the role of intermediary services?3Nonefhir_botTriagedReady-For-VoteNoneNone(profiles)<p>current language: if  coverage recommendations are being returned by a benefits manager or intermediary,</p> <p>The indicated intermediary is an organization acting on behalf of the responsible payer not an entity acting as a "clearing house" </p> <p>Will add clarifying language to indicated that the responsible insurer (as known to the provider/patient) should be displayed as the card.source and not the name any contracted intermediary (such as a UM service) acting on behalf of the responsible payer.</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDKensaku KawamotoNonePersuasive with Mod5/13/20196/24/2019
22196Don't require prefetch - CRD #45  Submitted by: Kensaku Kawamoto  (University of Utah) On behalf of:  (kensaku.kawamoto@utah.edu) Existing Wording: In future releases of this specification, this requirement may become a &lsquo;SHALL&rsquo;. Implementers are encouraged to provide feedback about this possibility as part of their ballot feedback. --- Comment: Recommend not making this a SHALL, unless we are making this a SHALL in CDS Hooks more generally. --- Summary: Don't require prefetch3Nonefhir_botTriagedReady-For-VoteNoneNone(profiles)<p>It's not currently a SHALL.  Feel free to comment if we tighten it to a SHALL in the future.  However, the purpose of an IG is to tighten expectations, so it would be legitimate to mandate something for CRD conformance that isn't mandatory in general.  That said, agree that - at least in the US - mandating this for CRD would essentially mandate support most places.</p>NoneAffirmativeNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDKensaku KawamotoNoneNot Persuasive5/13/20195/13/2019
22198Change these words to 'payer'. - CRD #47  Submitted by: Mary Kay McDaniel  (Cognosante) On behalf of:  (MaryKay.McDaniel@cognosante.com) Existing Wording: "insuer", change to "payer" --- Comment: 2.2.1. 3rd paragraph, 2nd and 3rd sentence. Uses the word insurer. 2.2.1 2nd paragraph, 1st sentence refers to Medicare Coverage 2.2.2 2nd paragraph, 2nd sentence refers to insurer-provided app BUT the graphic 2.3 in the right side refers to "payer".   Most may understand that insurer is also the payer and that if there is Medicare Coverage, Medicare rules always apply, but Medicare may not be the payer. Everywhere else we talk about 'payer'. --- Summary: Change these words to 'payer'.3Nonefhir_bot2.2TriagedReady-For-VoteNoneNoneusecasesNoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDMary Kay McDanielNonePersuasive5/13/20195/13/2019
22199Update the use case for CommunicationRequest. - CRD #48  Submitted by: Mary Kay McDaniel  (Cognosante) On behalf of:  (MaryKay.McDaniel@cognosante.com) Existing Wording: Hook Resource: CommunicationRequest - - providers often impose charges to transfer patient data to external organizations and agencies. Some of these charges can be covered by a patient&rsquo;s insurance and be subject to coverage requirements Proposed Wording: Perhaps something about "sent to provide supporting information" related to the initial request --- Comment: the words after CommunicationRequest are not a use case. --- Summary: Update the use case for CommunicationRequest.3Nonefhir_bot4.2.1.1TriagedReady-For-VoteNoneNone(profiles)<p>Currently reads as:<br /><a href="http://hl7.org/fhir/communicationrequest.html">CommunicationRequest</a> - providers often impose charges to transfer patient data to external organizations and agencies. Some of these charges can be covered by a patient’s insurance and be subject to coverage requirements</p> <p>Change the text to focus on the intent of the communicationrequest and eliminate any comments regarding cost of any such exchange.</p>NoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDMary Kay McDanielNonePersuasive with Mod5/13/20196/24/2019
22200either broken links or user confusion over what blue words are for. - CRD #49  Submitted by: Mary Kay McDaniel  (Cognosante) On behalf of:  (MaryKay.McDaniel@cognosante.com) --- Comment: Perhaps I'm confused about what words in blue are. Previous to this section, if you clicked on a word that was blue it takes you to another location. In this section and those following, some words in blue do take you to another section/url - others do not. --- Summary: either broken links or user confusion over what blue words are for.3Nonefhir_bot4.2.1.3TriagedReady-For-VoteNoneNone(profiles)<p>CDS Hooks links will all be fixed</p>NoneAffirmativeNone2019 May CRDCommentFinancial MgmtNoNoneUS Da Vinci CRDMary Kay McDanielNonePersuasive5/13/20195/13/2019
22218Unusual wording in use case sceanrio 3 - CRD #67  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: As Dr. Good is completing the referral, his EMR contacts Mr. Light&rsquo;s server which identifies that Proposed Wording: As Dr. Good is completing the referral, his EMR contacts the server of Mr. Light&rsquo;s health plan which identifies that --- Comment: It's weird to assign possession of the Payer's server to the patient. --- Summary: Unusual wording in use case sceanrio 33Nonefhir_botUse-cases Scenario 3TriagedReady-For-VoteNoneNoneusecasesNoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20195/13/2019
22220Remove references to CRD app; rename "EMR" to CRD client. - CRD #69  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: 2b. Provider starts &lsquo;CRD what-if&rsquo; --- Comment: Is there a functional, technical difference between the "EMR" and the "CRD app" in the IG? Is any of this IG actually limited to an "EMR" or CRD app?  I don't think that it is. Other types of software should be able to use CRD to call a CRD Service. These two actors should be collapsed into a single and more generic actor. Note that CDS Hooks refers to this actor as a CDS Client. In the "Formal Spec" page, section 4.1.3 Systems, you actually define your terms for these actors, but them fail to use those terms consistently. I'd recommend the terms CRD Client and CRD Service for accuracy. --- Summary: Remove references to CRD app; rename "EMR" to CRD client.3Nonefhir_botUse-cases CRD workflTriagedReady-For-VoteNoneNoneusecases<p>CRD app refers to a SMART app launched from the EMR rather than the EMR itself.  Will replace all references to CRD app with CRD SMART app</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive with Mod5/13/20195/13/2019
22222Don't unnecessarily interrupt the provider - CRD #71  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: A message describing what coverage requirements exist &hellip; The requirements themselves might include &hellip;  medical documentation that must exist or be provided --- Comment: Returning a card with textual description of a requirement of medical documentation should only be done after the payer has verified against the provider's FHIR server that this documentation does not exist. --- Summary: Don't unnecessarily interrupt the provider3Nonefhir_botUse-cases CRD workflTriagedReady-For-VoteNoneNoneusecases<p>Add the following wording:<br /> Payer SHALL avoid interrupting provider workflow wherever possible by accessing documentation in the patient's record via the JWT</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/17/2019
22223Use of the "Da Vinci CRD SMART app" should not be required to conform to CRD and should not be referenced explicitly in normative IG content. - CRD #72  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) --- Comment: A reference implementation of a simulated "what-if" CRD client should not be referenced in the IG except as a implementation artifact and potential resource to implementers. As it is, it's unclear if the use of this single, specific web application is a required to support CRD. --- Summary: Use of the "Da Vinci CRD SMART app" should not be required to conform to CRD and should not be referenced explicitly in normative IG content.3Nonefhir_botSMART on FHIR Hook ITriagedReady-For-VoteNoneNone(profiles)<p>Append the following the the paragraph ending with "app will interact with the payer systems using the existing SMART on FHIR interface."</p> <p>"Payers and EHRs may choose to use this app directly or use it as a basis for their own development.  Note that EHRs will have their own registration process for such apps."</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/17/2019
22224SMART app can't always access same FHIR resources as a CDS Service. - CRD #73  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Clients conforming with this application SHALL support the SMART on FHIR interface, allow launching of SMART apps from within their application and be capable of providing the SMART app access to the same resources it exposes to payer systems using the CDS Hooks interface. --- Comment: Note that the CDS Hooks specification differentiates contextual FHIR resources sent from the CDS client in the request from RESTful FHIR queries because there are cases in a user's workflow where an unsigned order or draft resource might not yet have been persisted to the database, but yet benefit from external CDS. This context/pre-fetch "push" of FHIR to the external CDS service is a unique capability that doesn't (currently) exist in SMART. --- Summary: SMART app can't always access same FHIR resources as a CDS Service.3Nonefhir_botSMART on FHIR Hook ITriagedReady-For-VoteNoneNone(profiles)<p>Will change the "SHALL" sentence to read:</p> <p>Clients conforming with this specification <strong>SHALL</strong> support the SMART on FHIR interface, allow launching of SMART apps from within their application and be capable of providing the SMART app access to the same resources it exposes to payer systems using the CDS Hooks interface via the FHIR server.  Note that servers are not expected to support the query of 'draft' resources made available as part of CDS Hooks context.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/17/2019
22227Allow client to require more secure, confidential SMART apps. - CRD #76  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Client systems SHALL support running applications that adhere to the SMART on FHIR public app profile --- Comment: This seems like an arbitrary requirement that is outside the basic purpose of the IG. Further, this requirement reduces security. --- Summary: Allow client to require more secure, confidential SMART apps.3Nonefhir_botHooks - Privacy, SecTriagedReady-For-VoteNoneNone(profiles)<p>Will change "public app" to "confidential app" and correct the link accordingly</p>NoneNegative-MajorNone2019 May CRDEnhancementFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/17/2019
22228Don't mandate business requirements in a FHIR IG. - CRD #77  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Payer systems that wish to receive Hook invocations that contain PHI SHALL demonstrate at time of registration/configuration that their user agreements give them permission to receive such data in a coverage requirement context. --- Comment: This requirement doesn't belong in a technical specification. This is a business requirement. --- Summary: Don't mandate business requirements in a FHIR IG.3Nonefhir_botHooks - Privacy, SecTriagedReady-For-VoteNoneNone(profiles)<p>We will remove this bullet.</p>NoneAffirmativeNone2019 May CRDCorrectionFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/17/2019
22229Don't mandate legal or business requirements in a FHIR IG. - CRD #78  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: However, client systems withholding information take on the responsibility of ensuring coverage requirements are met, even if discovery is no longer possible through the interfaces provided by this implementation guide. --- Comment: Does this belong in an interoperability standard? --- Summary: Don't mandate legal or business requirements in a FHIR IG.3Nonefhir_botHooks - Privacy, SecTriagedReady-For-VoteNoneNone(profiles)<p>Current wording: However, client systems withholding information take on the responsibility of ensuring coverage requirements are met, even if discovery is no longer possible through the interfaces provided by this implementation guide.</p> <p><br /> Replace with the following:  However, providers withholding information may take on the responsibility of ensuring coverage requirements are met, even if discovery is no longer possible through the interfaces provided by this implementation guide.</p>NoneAffirmativeNone2019 May CRDCorrectionFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive with Mod5/13/20196/24/2019
22230Don't require CRD clients to support both PHI and non-PHI - CRD #79  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Client systems SHALL determine whether a payer system should receive the PHI or non-PHI version of the CRD interface at the time the payer is configured to have access to their system. --- Comment: The split between PHI and non-PHI CRD services burdens the CRD Client and favors the CRD service. There are many more clients than services. This IG introduces essentially new FHIR resources to support this non-PHI scenario, including the somewhat nonsensical non-PHI Patient resource. Optimally, all CRD services would support a single set of PHI hooks. That's the best case scenario that would most likely accomplish the desired interoperability and improvements in care and cost. CRD clients should not be required to support the non-standard and less-functional non-PHI hooks. --- Summary: Don't require CRD clients to support both PHI and non-PHI3Nonefhir_botNon-PHI Hook InvocatTriagedReady-For-VoteNoneNone(profiles)<p>CMS and Medicaid do not need PHI to respond to CRD requests (only one plan).  In general PHI should not be exchanged unless there is a need.  Exposing PHI on roughly 50% of all viisits, unnecessarily must be weighed against the additional burden of adding profiles on two resources (Patient and Coverage) to eliminate the essential elements that constitute demographics and patient level identifiers (e.g. MRN). Proposal is to keep the current requirements to support both a PHI and non-PHI version of CRD.  Ballot submitter does not agree with this resolution.</p>NoneNegative-MajorNone2019 May CRDEnhancementFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNoneNot Persuasive5/13/20196/24/2019
22231No coverage requirements' should not create a card. - CRD #80  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Practitioners will rely on the information provided by the Coverage Requirements Discovery process to determine if there are any special steps they need to take such as requesting prior authorization. As a result, it&rsquo;s important to them to know definitively whether requirements exist or not. While potentially noisy, payers SHALL provide a message that says &ldquo;No coverage requirements for [ABC]&rdquo; if it is definitively known that there are no requirements for the proposed action or &ldquo;Unable to determine coverage requirements for [ABC] - please review [XYZ]&rdquo; or some equivalent when processing errors (e.g. unrecognized service code) prevent the payer from determining coverage requirements. --- Comment: CDS Hooks distniguishes between the lack of a response from a CDS service and the lack of guidance. It seems like the absence of coverage requirements should not generate an alert to a user. This approach is perfectly designed to generate provider burden: "While potentially noisy, payers SHALL provide a message that says &ldquo;No coverage requirements for [ABC]&rdquo; if it is definitively known that there are no requirements for the proposed action". Also, specifically note that an empty json object (the CDS Hooks mechanism for representing no guidance -- which is not shown to the user) allows a computer to distinguish between "no requirements" and a textual requirement (this is relevent to 4.5.2). --- Summary: No coverage requirements' should not create a card.3Nonefhir_botAdditional ConsideraTriagedReady-For-VoteNoneNone(profiles)<p>Modify the wording to allow individual providers, health systems, etc. to determine if the the provider be shown a card when there are no specific coverage requirements.</p> <p>Practitioners will rely on the information provided by the Coverage Requirements Discovery process to determine if there are any special steps they need to take such as requesting prior authorization. As a result, it’s important to them to know whether requirements exist or not.  Payers SHALL respond with an empty json object when there is no action to be taken by the provider (the CDS Hooks mechanism for representing no guidance -- which is not shown to the user) which allows a computer to distinguish between "no requirements" and a textual requirement (this is relevent to 4.5.2).</p>NoneNegative-MajorNone2019 May CRDEnhancementFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20196/24/2019
22236Add add'l workflow description to CDS Hooks - CRD #85  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: This hook would be triggered when a provider books a future appointment for the patient with themselves or their own organization as well as when they book an appointment for a patient with someone else. --- Comment: It would be nice to update the definition of the appointment-book hook on the CDS Hooks site to include the additional workflow information provided in the CRD IG. --- Summary: Add add'l workflow description to CDS Hooks3Nonefhir_botappointment-bookTriagedReady-For-VoteNoneNone(profiles)<p>Will do this</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20195/13/2019
22242What is this sentence intended to communicate? - CRD #91  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: The queries use the defined search parameter names from the respective FHIR specification versions. If parties processing these queries have varied from these &lsquo;standard&rsquo; search parameter names, they will be responsible for translating the parameters into their local names. --- Comment: This wording in the spec seems to be a tautology and therefore of limited usefulness -- if "parties" are using custom names, the standard names won't work &hellip; --- Summary: What is this sentence intended to communicate?3Nonefhir_botPrefetchTriagedReady-For-VoteNoneNone(profiles)<p>In FHIR, the names for query parameters are *recommended* names but are not mandated.  The actual names used by a given server are determined by the SearchParameter canonical URLs tied to each name by the server-specific CapabilityStatement.  This statement is saying that the prefetch queries presume 'standard' names.  If the EMR uses non-standard names, the queries will have to be adjusted accordingly.  (This should probably be guidance in the CDS Hooks spec.)</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDIsaac VetterNoneConsidered - Question Answered5/13/20195/13/2019
22244Why not standardize prefetch key names? - CRD #93  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: EMR implementations should not expect standardized prefetch key names. --- Comment: It seems like standardizing prefetch key names would be a great opportunity to simply and easily reduce optionality as part of this IG. Why not standardize them? --- Summary: Why not standardize prefetch key names?3Nonefhir_botPrefetchTriagedReady-For-VoteNoneNone(profiles)<p>The specific pre-fetch queries used by different payers will vary - due to the obligation to retrieve "minimum necessary".  The queries provided show what EMRs SHOULD support, but not what the actual prefetch queries form individual payers will actually be.  As such, there's no benefit to trying to standardize.  (As well, the underlying standard requires systems to look at the supplied queries anyhow, so standardizing wouldn't save much.)</p>NoneNegative-MajorNone2019 May CRDEnhancementFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20195/13/2019
22247Services should be required to provide what coverage requirements they're able to based on available information. - CRD #96  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: Services SHOULD provide what coverage requirements they can based on the information available. Proposed Wording: Services SHALL provide what coverage requirements they can based on the information available. --- Comment: Why isn't this a SHALL? If a CRD service doesn't return coverage requirements based on available information even though it "can"; that service ought not to be compliant with the IG. --- Summary: Services should be required to provide what coverage requirements they're able to based on available information.3Nonefhir_botPrefetchTriagedReady-For-VoteNoneNone(profiles)<p>Make this SHALL</p>NoneNegative-MajorNone2019 May CRDClarificationFinancial MgmtYesNoneUS Da Vinci CRDIsaac VetterNonePersuasive5/13/20195/13/2019
22248Why does CRD recommend how FHIR whitespace is handled? - CRD #97  Submitted by: Michael Clifton  (Cognosante) On behalf of: Isaac Vetter (isaac@epic.com) Existing Wording: 1. The examples in this guide use whitespace for readability. Conformance systems SHOULD omit non-significant whitespace for performance reasons --- Comment: Does this belong in a FHIR IG? Regardless of the merit of the recommendation; this should either be in the core FHIR spec or not a recommendation at all. This is way outside the core domain of the IG. --- Summary: Why does CRD recommend how FHIR whitespace is handled?3Nonefhir_botAdditonal ConsideratTriagedReady-For-VoteNoneNone(profiles)<p>Implementers commonly implement examples "as seen".  The purpose of the comment was to call attention to the fact that a more concise syntax is desired.  While some implementers may find the recommendation unnecessary, those being targeted by the comment will not.</p>NoneAffirmativeNone2019 May CRDQuestionFinancial MgmtNoNoneUS Da Vinci CRDIsaac VetterNoneConsidered - Question Answered5/13/20195/13/2019
22254It is difficult to effectively provide commentary on whether we agree with a technology that is still yet to be published. - CRD #103  Submitted by: Terrence Cunningham  (Scope Infotech) On behalf of:  (terrence.cunningham@ama-assn.org) --- Comment: It is troubling to see a yet to be released technology as the technological base for our ballot.  Our ballot heavily references CDS Hooks, which is still potentially under significant revision processes, thus making this ballot effectively asking for comments on something that might change significantly. --- Summary: It is difficult to effectively provide commentary on whether we agree with a technology that is still yet to be published.3Nonefhir_bot4.2.1 CDS HooksTriagedReady-For-VoteNoneNone(profiles)<p>CDS Hooks has passed STU ballot and has been published.  At the time of ballot, the specification referenced the 'final' version of the specification that was awaiting publication.  The referenced specification has proven sufficient to support implementation of numerous implementations in a wide variety of EMR, payer and other systems, so it should have been more than adequate to evaluate.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDTerrence CunninghamNoneNot Persuasive5/13/20195/13/2019
22259There needs to be an avenue to addressing any shortcoming conveyed up front. - CRD #108  Submitted by: Terrence Cunningham  (Scope Infotech) On behalf of:  (terrence.cunningham@ama-assn.org) Existing Wording: &ldquo;Unable to determine coverage requirements for [ABC] - please review [XYZ]&rdquo; or some equivalent when processing errors --- Comment: The second clause of this sentence is particularly important, as it points to a specific technical error or issue to be resolved in order to make the CRD processable.  In order to prevent a situation where a payer can simply say "We are not sure&hellip; this is pended", which often results in the need for a phone call and can delay care, there needs to be an avenue to addressing any shortcoming conveyed up front. --- Summary: There needs to be an avenue to addressing any shortcoming conveyed up front.3Nonefhir_bot4.5 (1) Additional CTriagedReady-For-VoteNoneNone(profiles)<p>We agree this would be desirable, however there is no guarantee that there will always be a computable mechanism to communicate what's needed to resolve a payer's issues.  Our objective is to significantly reduce the situation where a phone call is needed, but we're under no illusions that they'll ever be totally eliminated from the process.</p>NoneAffirmativeNone2019 May CRDCommentFinancial MgmtNoNoneUS Da Vinci CRDTerrence CunninghamNoneConsidered - No action required5/13/20195/13/2019
22261The ballot is undergoing several updates pending connectathon and additional testing results - CRD #110  Submitted by: Walter Suarez  (Kaiser Permanente) On behalf of:  (walter.g.suarez@kp.org) --- Comment: 1) The ballot is undergoing several updates pending connectathon and additional testing results --- Summary: The ballot is undergoing several updates pending connectathon and additional testing results3Nonefhir_botGeneralTriagedReady-For-VoteNoneNone(NA)<p>That is true.  It's unclear why that justifies a negative ballot.  As a standard for trial use, there is expected to be a period of ballot, implement, adjust, reballot as the community gains implementation experience and adjusts the specification to best meet its needs</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDWalter SuarezNoneNot Persuasive5/13/20195/13/2019
22262Several parts of the ballot reference proposals recently submitted to correct external resources or proposal that are still pending to be resolved - CRD #111  Submitted by: Walter Suarez  (Kaiser Permanente) On behalf of:  (walter.g.suarez@kp.org) --- Comment: 2) several parts of the ballot reference proposals recently submitted to correct external resources or proposal that are still pending to be resolved --- Summary: Several parts of the ballot reference proposals recently submitted to correct external resources or proposal that are still pending to be resolved3Nonefhir_botTriagedReady-For-VoteNoneNone(NA)<p>That is true.  It's not clear why that's a rationale for a negative vote.  This specification is intended to be implementable - not necessarily locked down or totally stable.  (Under HL7 rules, a totally locked down standard wouldn't be possible for about 4 years - after considerable implementation experience.)  We have specifically highlighted those parts where proposals are in progress to alert implementers as to which portions are specifically known to be vulnerable to future change.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDWalter SuarezNoneNot Persuasive5/13/20195/13/2019
22263The IG relies heavily on CDS-HOOKS which is still under major development - CRD #112  Submitted by: Walter Suarez  (Kaiser Permanente) On behalf of:  (walter.g.suarez@kp.org) --- Comment: 3) the IG relies heavily on CDS-HOOKS which is still under major development --- Summary: The IG relies heavily on CDS-HOOKS which is still under major development3Nonefhir_botTriagedReady-For-VoteNoneNone(NA)<p>CDS Hooks has passed STU ballot and has significant support (and implementation underway) by most significant US EMR vendors.  This specification is also at STU level.  CDS Hooks is not significantly less mature than any of the other possible options and is the one that's been endorsed as most appropriate by the stakeholders who will be implementing it.</p>NoneNegative-MajorNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDWalter SuarezNoneNot Persuasive5/13/20195/13/2019
22264Specifically indicate to the provider if a Prior Authorization is required or not for the specific service or procedure. - CRD #113  Submitted by: Rachel Foerster  (Rachel Foerster & Associates Ltd.) On behalf of:  (rachel@rfa-edi.com) --- Comment: The Cards returned in response to a CDS Hooks query need to have some that are standardized and required to specifically indicate to the provider if a Prior Authorization is required or not for the specific service or procedure. --- Summary: Specifically indicate to the provider if a Prior Authorization is required or not for the specific service or procedure.3Nonefhir_botTriagedReady-For-VoteNoneNone(profiles)<p>There are several different types of cards that could be returned to indicate whether prior authorization is required - external reference, instructions, request form completion and/or launch SMART app.  We don't want to constrain payers and there's no particular benefit to EMRs to trying to standardize further.</p>NoneAffirmativeNone2019 May CRDEnhancementFinancial MgmtNoNoneUS Da Vinci CRDRachel FoersterNoneNot Persuasive5/13/20195/13/2019
22266Version History is not present - shouldn't September version be listed - CRD #115  Submitted by: Linda Michaelsen  (Optum) On behalf of:  (linda.michaelsen@optum.com) --- Comment: Version History is not present - shouldn't September version be listed --- Summary: Version History is not present - shouldn't September version be listed3Nonefhir_botTriagedReady-For-VoteNoneNone(many)<p>It is listed.  Just click on the 'History' link on the Main menu.  The Sept. ballot is the one listed at the bottom of the table.</p>NoneAffirmativeNone2019 May CRDCorrectionFinancial MgmtNoNoneUS Da Vinci CRDLinda MichaelsenNoneNot Persuasive5/13/20195/13/2019
22267Figures such as on Use Cases and Overview?page should be numbered for easier reference - CRD #116  Submitted by: Linda Michaelsen  (Optum) On behalf of:  (linda.michaelsen@optum.com) --- Comment: Figures such as on Use Cases and Overview?page should be numbered for easier reference --- Summary: Figures such as on Use Cases and Overview?page should be numbered for easier reference3Nonefhir_botTriagedReady-For-VoteNoneNoneusecases<p>Will number</p>NoneAffirmativeNone2019 May CRDClarificationFinancial MgmtNoNoneUS Da Vinci CRDLinda MichaelsenNonePersuasive5/13/20195/13/2019