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

Difference between revisions of "Xxxxx FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
Line 13: Line 13:
  
  
=PutProposedResourceNameHere=
+
=SecurityPrincipal=
 
 
<!-- Resource names should meet the following characteristics:
 
* Lower camel case
 
* U.S. English
 
* Domain-friendly
 
* Short
 
* Clear
 
* Unique
 
* Avoid non-universal abbreviations (e.g. URL would be ok)
 
* Be expressed as a noun
 
* Be consistent with other similar resources
 
-->
 
  
 
==Owning committee name==
 
==Owning committee name==
  
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
+
FHIR Core Project
[[YourCommitteeName]]
 
  
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
  
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
+
* Security
* Work Group Name
+
* IHE
* or link
 
* or "None"
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
  
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
+
FHIR core project
  
 
==Scope of coverage==
 
==Scope of coverage==
  
<!-- Define the full scope of coverage for the resource. The scope must be clearly delineated such that it does not overlap with any other existing or expected resource.  The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%"
+
Some implementations find that it would be useful to be able to manage user accounts and rights through the FHIR interface. This is true whether they use their own user identity system, or some external identity provider such as LDAP, Windows Domain, or Facebook/Google/etc,since even when using these external identity providers, there are still rights/roles things to say that are specific about FHIR. So we have decided that FHIR will provide a specific set of resources for this. Note that it will not be required for an implementation to use these resources in order to implement it's security system - they are defined for convenience should an implementation wish one.  
 
 
Scope should consider numerous aspects of breadth of scope, including:
 
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
 
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
 
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
 
* Locale: Country, region
 
  
As a rule, resources should encompass all of these aspects.
+
The SecurityPrincipal resource allows a system to describe either human user or a device/software application that is authorised to use the FHIR API, and manage both how it is authenticated, and what authorisations it has.  
-->
+
* subject: either device or person (or perhaps organisation)
 +
* usage: manage authentication and/or authorization
 +
* this resource is not limited by discipline/context/locality
  
 
==RIM scope==
 
==RIM scope==
  
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
+
* A principle is an entity (Person/Organisation/Device) playing the role of Licensed Entity (LIC)
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
<!-- Does the resource meet the following characteristics?
+
This resource represents:
 
+
* a well understood, "important" concept in the business of healthcare - an authenticated.
Must
+
** note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become and API dependency
* Represents a well understood, "important" concept in the business of healthcare
+
* a concept (user/device) expected to be tracked with distinct, reliable, unique ids
* Represents a concept expected to be tracked with distinct, reliable, unique ids
+
* a concept that is created, queried and maintained
* Reasonable for the resource to be independently created, queried and maintained
+
* the initial proposal expects 10 elements
 
+
* is well decoupled from other concepts
Should
 
* Declared interest in need for standardization of data exchange</span>
 
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document
 
-->
 
  
 
==Expected implementations==
 
==Expected implementations==
  
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
+
* the FHIR reference server will implement this
 +
* several other connectathon attendees have asked for this functionality
  
 
==Content sources==
 
==Content sources==
  
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
+
* IHA XUA
 
+
* OpenID Connect
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
+
* Microsoft Documentation - WCF Security & LDAP documentation
  
 
==Example Scenarios==
 
==Example Scenarios==
  
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
+
* define user/software that is allowed to use a server
 +
* define claims for rights that apply to an identified user or software application
  
 
==Resource Relationships==
 
==Resource Relationships==
  
<!-- What are the resources do you expect will reference this resource and in what context?
+
* this resource refers to other resources that identify the same principal (patient, practitioner, organization, device)
 
+
* this resource refers to a security rights group for grouping claims of rights
What resources do you expect this resource reference and in what context?
+
* there is also a SecurityRole group for defining additional roles a user may claim
 
 
Note: These may be existing resources or "expected" resource
 
 
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
-->
 
  
 
==Timelines==
 
==Timelines==
  
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
+
Fro development for QA/DSTU2
  
 
==gForge Users==
 
==gForge Users==
  
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
+
Core team

Revision as of 20:58, 18 May 2014



SecurityPrincipal

Owning committee name

FHIR Core Project

Contributing or Reviewing Work Groups

  • Security
  • IHE

FHIR Resource Development Project Insight ID

FHIR core project

Scope of coverage

Some implementations find that it would be useful to be able to manage user accounts and rights through the FHIR interface. This is true whether they use their own user identity system, or some external identity provider such as LDAP, Windows Domain, or Facebook/Google/etc,since even when using these external identity providers, there are still rights/roles things to say that are specific about FHIR. So we have decided that FHIR will provide a specific set of resources for this. Note that it will not be required for an implementation to use these resources in order to implement it's security system - they are defined for convenience should an implementation wish one.

The SecurityPrincipal resource allows a system to describe either human user or a device/software application that is authorised to use the FHIR API, and manage both how it is authenticated, and what authorisations it has.

  • subject: either device or person (or perhaps organisation)
  • usage: manage authentication and/or authorization
  • this resource is not limited by discipline/context/locality

RIM scope

  • A principle is an entity (Person/Organisation/Device) playing the role of Licensed Entity (LIC)

Resource appropriateness

This resource represents:

  • a well understood, "important" concept in the business of healthcare - an authenticated.
    • note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become and API dependency
  • a concept (user/device) expected to be tracked with distinct, reliable, unique ids
  • a concept that is created, queried and maintained
  • the initial proposal expects 10 elements
  • is well decoupled from other concepts

Expected implementations

  • the FHIR reference server will implement this
  • several other connectathon attendees have asked for this functionality

Content sources

  • IHA XUA
  • OpenID Connect
  • Microsoft Documentation - WCF Security & LDAP documentation

Example Scenarios

  • define user/software that is allowed to use a server
  • define claims for rights that apply to an identified user or software application

Resource Relationships

  • this resource refers to other resources that identify the same principal (patient, practitioner, organization, device)
  • this resource refers to a security rights group for grouping claims of rights
  • there is also a SecurityRole group for defining additional roles a user may claim

Timelines

Fro development for QA/DSTU2

gForge Users

Core team