Skip to end of metadata
Go to start of metadata

Current Projects being developed:

  1. 32 CFR Part 2002 CUI
  2. 42 CFR Part 2
  3. Title 38 Section 7332

Potential Projects (Notes from AU WGM February 5, 2020)

  1. Clinical Research Project
    1. Models
      1. with re-identification need
      2. with NO re-identification need
    2. using Provenance, using encrypted, ???
  2. Public Health reporting - sending data to registry
    1. Patient has no say, as it is regulated 
    2. How should public health requests be defined as distinct from other requests?
      1. security assertion as PurposeOfUse=publicHealth, with user/role derived from trusted authority representing publicHealth.
    3. How should residual obligations or restrictions be contained (data tagging vs Permission resource)
    4.  Models
    5. Maturity
      1. Simple – only uses PurposeOfUse with no other tags or resource
      2. Moderate - include on Bundle the expected obligations for the use-case of public health reporting – Do Not Redisclose, etc..
      3. Advanced - Permission is used to express these obligations and to publish on the endpoint used (capabilityStatement leverages the Permission)
  3. How to indicate that data are available for Secondary Use
    1. How to indicate that data are available for secondary use, vs forbidden to secondary use
    2. Models
      1. Data Tagging?
      2. Permit/Deny
      3. Use of Consent
      4. Use of Permission
  4. Individual Patient Control
    1. Dominated by Consent but would have support for data tagging as a segmentation mechanism
  5. Delegation of Control
    1. Note that this has likely no affect on data tagging, but would have strong reliance on Consent
  6. AU - My Health Record Act
    1. likely leverage Delegation of Controls and Individual Patient Control IG?
  7. Export/Import support for continuity of Policy linkage
    1. As data gets imported, the "id" often is fixedup to local service, thus policy associated with that imported data must also be fixedup so as to not loose the linkage between data and policy controlling the use of that data
    2. Models (thus there may be an IG for each of these models because they are different)
      1. Central policy service - 
      2. Push policy (Permission resource or Consent resource) with data. Importer has responsibility  upon import
      3. Policy always uses business identifiers (.identifier) and not resource id (.id); thus is not impacted by import fixup
  8. Where data are tagged with indication of the policy service that can be queried about appropriate use of the data
    1. Where Provenance resource is used as the linkage between the data and the policy (Provenance.target → Data; Provenance.policy → Policy service)
    2. Extension on DomainResource adding an endpoint element
    3. All require some definition of the policy service API 
      1. Could be OAuth 
        1. SMART on FHIR
        2. HEART
      2. Could be Consent resource
      3. Could be Permission
      4. Could be some operation defined in the IG
  9. BreakGlass
    1. Choice given at first access request on if normal or breakglass is declared
    2. Data are blinded with no indication to clincian, but they can still declare breakglass to see if more data are avaiable
    3. Data are blinded with an indication to clinician that there is data withheld, with option to break glass
    4. Use of AuditEvent in all cases
    5. Requirements for Privacy/Safety office to investigate AuditEvents of breakglass
  • No labels