The specifications must meet the following basic requirements, in addition to specific use cases and requirements later identified by this Working Group:

• Support the exchange of health-related data across security domains.
• Support independent authorization services and identity providers, to be chosen by people who may build, run, or outsource these services.
• Recognize that health data is high-value, personal, sensitive data that requires appropriate security, access controls, privacy protections, and consent obligations.
• Recognize that health-related systems are often both requesters and providers of data.
• Allow an individual to manage data sharing relationships, including modifying the conditions of access or terminating the relationship entirely.
• Allow an individual to audit and monitor various aspects of data-sharing relationships, notably access and usage.

The specifications and profiles must meet the following basic design principles, in addition to any emergent design principles later identified by this Working Group:

• Simple to understand, to implement in an interoperable fashion, and to deploy on an Internet-wide scale.
• Based on the OAuth 2.0 IETF RFCs, the OpenID Connect specifications published by the OpenID Foundation, and the User-Managed Access (UMA) specifications developed at the Kantara Initiative and submitted to the IETF to the extent possible, while contributing bug reports and RFEs around extensibility, security, and privacy to the relevant working groups.
• Leverage lessons learned from the Blue Button+, RHEx and other initiatives and their profiles to the extent possible, and leverage FHIR as a key exemplar of a health data API, recognizing that additional features may be required.
• Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible.
• Layered and loosely coupled.
• Generative (able to be combined and extended to support a variety of use cases in other application domains and emerging application functionality).
• Developed rapidly, in an “agile specification” process that can refactor for emerging needs.

This Working Group will target producing use cases and requirements within 2 months of inception in order to guide its design effort, and will target 6-12 months overall to develop a V1.0 set of profiles and other auxiliary materials, facilitating the development of multiple independent draft implementations as appropriate during this time. The following are suggested initial milestones for consideration by the Working Group:

• GIS Sept 2015: Approval of WG creation
• TBD Event to announce Implementer’s drafts (NLT 12 months after formal kickoff of WG).
• Interop testing among multiple implementations (once Implementer’s Drafts are available)
• TBD Event to announce Final profiles (NLT 6-12 months after Implementer’s Drafts)

The specifications must meet the following basic requirements, in addition to specific use cases and requirements later identified by this Working Group:

• Support the exchange of health-related data across security domains.
• Support independent authorization services and identity providers, to be chosen by people who may build, run, or outsource these services.
• Recognize that health data is high-value, personal, sensitive data that requires appropriate security, access controls, privacy protections, and consent obligations.
• Recognize that health-related systems are often both requesters and providers of data.
• Allow an individual to manage data sharing relationships, including modifying the conditions of access or terminating the relationship entirely.
• Allow an individual to audit and monitor various aspects of data-sharing relationships, notably access and usage.

The specifications and profiles must meet the following basic design principles, in addition to any emergent design principles later identified by this Working Group:

• Simple to understand, to implement in an interoperable fashion, and to deploy on an Internet-wide scale.
• Based on the OAuth 2.0 IETF RFCs, the OpenID Connect specifications published by the OpenID Foundation, and the User-Managed Access (UMA) specifications developed at the Kantara Initiative and submitted to the IETF to the extent possible, while contributing bug reports and RFEs around extensibility, security, and privacy to the relevant working groups.
• Leverage lessons learned from the Blue Button+, RHEx and other initiatives and their profiles to the extent possible, and leverage FHIR as a key exemplar of a health data API, recognizing that additional features may be required.
• Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible.
• Layered and loosely coupled.
• Generative (able to be combined and extended to support a variety of use cases in other application domains and emerging application functionality).
• Developed rapidly, in an “agile specification” process that can refactor for emerging needs.

• This charter uses the word “individual” in the ordinary English sense vs. in the sector-specific sense defined by HIPAA.
• This charter uses the phrase “layered specification” to distinguish the generic notion of a modular technical specification (broken into reusable pieces to enable a “call tree” of references from multiple higher-level specifications) vs. the sector-specific sense of a “mod spec”.