Consent in Queries

Use-case: consent based on

• 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.

Emergency override: in v3 terms, see DetectedIssue and DetectedIssueManagament classes in the ControlAct wrapper. Supply a (textual) reason for doing so as well.

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.

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.
• Medical Records DSTU: once it goes forward to normative cycle, add solution

MedRec THU Q4 Minutes

(to be merged with aboved text into 1 coherent page)

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.