This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Consent in Queries"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
{{INM Workitem}}
 
{{INM Workitem}}
−
Use-case: consent based on
+
There are use-cases for including [[Consent]]information in a query. [[DetectedIssueManagement]] may be based on having consent.
−
*Legitimate Relationship (UK term), Certificate of Care Relationship (Finnish term). Consent is explicit/implicit related to e.g. the fact the GP has a relationship with a Patient
 
−
*Consent form: granting acces to data, created/signed by patient
 
−
*Identity of requester,  we know/trust requester, have a contract with them
 
  
−
In queries, in Finland may need to send more that just the ID of the consent document instance, or the ID of the Certificate of Care Relationship. Consent may be in central reporsitory, in which case it may be referenced. May require a medical-records (or new, if consent is a mesage model instead of a document) interaction to convey the consent. Depends on level of trust, in NL the ID may be sufficient, because during audit you better have the full document. In US no national provider IDs, no PKI infrastructure, combined with HIPAA makes situation compex. In Canada business rules will vary across 13 provincial jurisdictions.
+
Suggestion is to add consent.id (a reference to the full consent model) in the ControlAct wrapper wrapper, and not to add support in the wrapper for the scanned consentform nor of a fullblown consent model. The full consent could be stored (and referenced) once uploaded into a registry, or it could be transmitted in the form of an Attachment class in Transmission Wrapper.
  
−
Emergency override: in v3 terms, see DetectedIssue and DetectedIssueManagament classes in the ControlAct wrapper. Supply a (textual) reason for doing so as well.
+
A query may be executed based on:
 +
*a Legitimate Relationship (LR, an UK NHS term), or a Certificate of Care Relationship (Finnish term). Consent is explicit/implicit related to e.g. the fact the GP has a relationship with a Patient
 +
*a (written) consent form, granting acces to data, created/signed by patient
 +
*the identity of requester, we know/trust the requester, we have a contract with the particular requester
  
−
DetectedIssueManagement may be based on having consent. Only have consent.id (reference) in wrapper, not full scanned consentform. Have full consent in registry, or in Attachment class in Transmission Wrapper.
+
In those cases were consent information is conveyed in a query, what level of detail do we need?
 +
*In queries, in Finland may need to send more that just the ID of the consent document instance, or the ID of the Certificate of Care Relationship. Consent may be in central reporsitory, in which case it may be referenced. May require a medical-records (or new, if consent is a mesage model instead of a document) interaction to convey the consent. Depends on level of trust.
 +
*In the Netherlands the ID of the consent form may be sufficient, during an audit you (as a requester that referenced a consent ID in a query) better have the full document.
 +
*In the US there are no national provider IDs, there is no PKI infrastructure. This, combined with HIPAA, makes the consent situation complex.
 +
*In Canada business rules will vary across 13 provincial jurisdictions.
  
 
Note on Consent.txt: In terms of the consent model, a more accurate model might be to say that the consent is an instance of a consent definition, where the text of the definition reflects the "form".  Alternatively, it could represent the complete filled in form, which would presumably address the subject, performer, etc.
 
Note on Consent.txt: In terms of the consent model, a more accurate model might be to say that the consent is an instance of a consent definition, where the text of the definition reflects the "form".  Alternatively, it could represent the complete filled in form, which would presumably address the subject, performer, etc.
Line 15: Line 19:
 
Actions:  
 
Actions:  
 
*w/ Bob Dolin, create controlAct R-MIM with Consent, suggest ways to pre-adopt it.  
 
*w/ Bob Dolin, create controlAct R-MIM with Consent, suggest ways to pre-adopt it.  
−
*Medical Records DSTU: once it goes forward to normative cycle, add solution
 
  
−
 
+
'''September2006 WGM, THU Q4: Motion by the MR/IM TC:'''
−
==MedRec THU Q4 Minutes==
+
The following items were agreed to by a vote of 5-0-1.
−
 
+
*We will add this to the open issues log for the consent DSTU.
−
(to be merged with aboved text into 1 coherent page)
+
*At the time we take the DSTU to normative ballot (in 18 months) this will be addressed.
−
 
+
*We will let the current DSTU pass and anything that is needed by a realm at this time can tke it on as a realm extension.
−
Q4: V3 Ballot reconciliations with the Rene Spronk and Jari porrasmaa.
 
−
• Jari explained that the consent ID he was requesting be added was not information relating to a patient authorization but rather a clinician ID for indicating his permission to query the registry/repository/directory.
 
−
• Bob Dolin’s feeling is that conset ID is either not enough (you’d need more identifying information) or it’s not needed.
 
−
• Rene shared how this is accomplished in the Netherlands:
 
−
o Each person is assigned a primary care physician who has access to everything.
 
−
o All clinicians are assigned a “PKI” card from a trusted national source.  This ensures that the registry knows that the query is from who they say it’s from.
 
−
o Role based access control is the goal.
 
−
o Emergency override is allowed.  It’s in the control wrapper and sent in the initial query.
 
−
• This is immediately honored because you are a provider and textual reason why it was necessary was entered.
 
−
• In Finland there is a “certificate of care relationship” that is digitally signed by the patient administration system.  Without something similar to a Consent ID the entire document would need to be sent.  In the UK it’s known as a “legitimate relationship”.
 
−
• Bob stated the semantic requirements could be put in the domain acts rather than the control act query.
 
−
• Gary Cruickshank – currently the consent query has a consent c-met that would contain information or the actual consent.
 
−
• Additional discussion included
 
−
o The consent document is sent to the registry/repository/directory and is assigned an ID which in future queries can be referred to and used to identify the document when audited.
 
−
o The “detected issue class” in the control act is not meant to contain the scanned document.
 
−
o This is a slightly different type of consent than currently exists in the model.
 
−
o May need to publish a control act wrapper in our domain or pre-adopt a pre-approved INM wrapper.
 
−
 Could assign it an artifact
 
−
o Rene stated that INM has quite a laundry list of things to accomplish so he strongly suggested that we go with one of the pre-approved wrapper’s in order to keep moving forward.
 
−
• The following items were agreed to by a vote of 5-0-1.
 
−
o We will add this to the open issues log for the DSTU.
 
−
o At the time we take the DSTU to normative ballot (in 18 months) this will be addressed.
 
−
We will let the current DSTU pass and anything that is needed by a realm at this time can tke it on as a realm extension.
 

Revision as of 16:18, 4 October 2006

INM workitem.gif

This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.

There are use-cases for including Consentinformation in a query. DetectedIssueManagement may be based on having consent.

Suggestion is to add consent.id (a reference to the full consent model) in the ControlAct wrapper wrapper, and not to add support in the wrapper for the scanned consentform nor of a fullblown consent model. The full consent could be stored (and referenced) once uploaded into a registry, or it could be transmitted in the form of an Attachment class in Transmission Wrapper.

A query may be executed based on:

  • a Legitimate Relationship (LR, an UK NHS term), or a Certificate of Care Relationship (Finnish term). Consent is explicit/implicit related to e.g. the fact the GP has a relationship with a Patient
  • a (written) consent form, granting acces to data, created/signed by patient
  • the identity of requester, we know/trust the requester, we have a contract with the particular requester

In those cases were consent information is conveyed in a query, what level of detail do we need?

  • In queries, in Finland may need to send more that just the ID of the consent document instance, or the ID of the Certificate of Care Relationship. Consent may be in central reporsitory, in which case it may be referenced. May require a medical-records (or new, if consent is a mesage model instead of a document) interaction to convey the consent. Depends on level of trust.
  • In the Netherlands the ID of the consent form may be sufficient, during an audit you (as a requester that referenced a consent ID in a query) better have the full document.
  • In the US there are no national provider IDs, there is no PKI infrastructure. This, combined with HIPAA, makes the consent situation complex.
  • In Canada business rules will vary across 13 provincial jurisdictions.

Note on Consent.txt: In terms of the consent model, a more accurate model might be to say that the consent is an instance of a consent definition, where the text of the definition reflects the "form". Alternatively, it could represent the complete filled in form, which would presumably address the subject, performer, etc.

Actions:

  • w/ Bob Dolin, create controlAct R-MIM with Consent, suggest ways to pre-adopt it.

September2006 WGM, THU Q4: Motion by the MR/IM TC: The following items were agreed to by a vote of 5-0-1.

  • We will add this to the open issues log for the consent DSTU.
  • At the time we take the DSTU to normative ballot (in 18 months) this will be addressed.
  • We will let the current DSTU pass and anything that is needed by a realm at this time can tke it on as a realm extension.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Consent_in_Queries&oldid=9355"