Difference between revisions of "Consent in Queries"
Rene spronk (talk | contribs) |
|||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{INM Workitem}} | {{INM Workitem}} | ||
| − | There are use-cases for including [[Consent]]information in a query. [[ | + | There are use-cases for including [[Consent]] information in a query. |
| + | |||
| + | Any issues related to trigger event that will normally be refused by a receiver for authorization reasons, but where there is a consent which then results in the transmission being processed are modelled in the controlAct wrapper. Maybe not the full consent itself (although we could discuss adding a CMET), but at least the id of the consent act. The omission of a consent could lead to a [[Detected Issue]]. If one has the ability to convey the id (or: the details) of the consent the potential detected issue can be managed. | ||
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. | 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. | ||
| + | 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. | ||
| + | |||
| + | ==Consent use-cases in queries== | ||
A query may be executed based on: | 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 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 | ||
| Line 10: | Line 15: | ||
In those cases were consent information is conveyed in a query, what level of detail do we need? | 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 | + | *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 repository, 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 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 the US there are no national provider IDs, there is no PKI infrastructure. This, combined with HIPAA, makes the consent situation complex. Simply telling the repository that you have a consent.id doesn't seem sufficient - they have to know you, be involved in a trusting relationship with you. If they have that trusting relationship, then they can log that they released a document to you, and it's not clear that they must also log the consent id. If we start including consents in the query, I don't think it's any longer a query because the requester won't automatically act on it without reviewing the consent. |
*In Canada business rules will vary across 13 provincial jurisdictions. | *In Canada business rules will vary across 13 provincial jurisdictions. | ||
| − | + | ==Discussion== | |
| − | |||
| − | |||
| − | |||
| − | |||
'''September2006 WGM, THU Q4: Motion by the MR/IM TC:''' | '''September2006 WGM, THU Q4: Motion by the MR/IM TC:''' | ||
The following items were agreed to by a vote of 5-0-1. | The following items were agreed to by a vote of 5-0-1. | ||
| Line 25: | Line 26: | ||
*At the time we take the DSTU to normative ballot (in 18 months) this will be addressed. | *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. | *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. | ||
| + | |||
| + | |||
| + | 20070110: WGM, Thur Q2: | ||
| + | |||
| + | Is related to ManagedIssue calss in controlAct. | ||
| + | |||
| + | There is a use-case however whereby data is masked, and full data will only be disclosed when a consent is present. Ins uch cases there won't be an detectedIssue class. | ||
| + | |||
| + | CA have put consent CMET in CACT wrapper, associated with CACT class. Subject association. | ||
| + | |||
| + | Action: Michael/Kathleen bring relevant CA material forward. | ||
| + | |||
| + | Need to look at required garularity of the consent CMET in CACT wrapper. For example: [identified] , [universal]. | ||
Latest revision as of 18:48, 11 January 2007
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 Consent information in a query.
Any issues related to trigger event that will normally be refused by a receiver for authorization reasons, but where there is a consent which then results in the transmission being processed are modelled in the controlAct wrapper. Maybe not the full consent itself (although we could discuss adding a CMET), but at least the id of the consent act. The omission of a consent could lead to a Detected Issue. If one has the ability to convey the id (or: the details) of the consent the potential detected issue can be managed.
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.
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.
Consent use-cases in queries
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 repository, 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. Simply telling the repository that you have a consent.id doesn't seem sufficient - they have to know you, be involved in a trusting relationship with you. If they have that trusting relationship, then they can log that they released a document to you, and it's not clear that they must also log the consent id. If we start including consents in the query, I don't think it's any longer a query because the requester won't automatically act on it without reviewing the consent.
- In Canada business rules will vary across 13 provincial jurisdictions.
Discussion
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.
20070110: WGM, Thur Q2:
Is related to ManagedIssue calss in controlAct.
There is a use-case however whereby data is masked, and full data will only be disclosed when a consent is present. Ins uch cases there won't be an detectedIssue class.
CA have put consent CMET in CACT wrapper, associated with CACT class. Subject association.
Action: Michael/Kathleen bring relevant CA material forward.
Need to look at required garularity of the consent CMET in CACT wrapper. For example: [identified] , [universal].
