This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201709 GraphQL"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
Line 2: Line 2:
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
 
__NOTOC__
 
__NOTOC__
=Track Name=
+
=GraphQL Track=
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
<!-- Who is asking for this track? -->
+
Grahame Grieve on behalf of FHIR-I/AID
  
 
==Justification==
 
==Justification==
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
+
 
 +
There has been ongoing implementer interest in a more agile way to fetch data from a FHIR server, and some implementers have told me that they won't use FHIR because of this.
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
Grahame Grieve (looking for handover)
See [[Connectathon_Track_Lead_Responsibilities]]
 
  
 
==Expected participants==
 
==Expected participants==
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
+
* test.fhir.org
 +
* hapi server
  
 
==Roles==
 
==Roles==
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
+
===Server===
===Role 1 Name===
+
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
Makes data available through a graphQL interface:
 +
 
 +
# support query a patient resource using graphQL (or Observation)
 +
# support forward reference - follow Patient.generalPractitioner (or Observation.subject)
 +
# support search - allow search on patients
 +
# support publish metadata describing 1-3
 +
 
 +
Servers should list which steps they implement on the tracking spreadsheets
 +
 
 +
=== Client ===
 +
 
 +
# query a patient resource using graphQL (or Observation)
 +
# forward reference - follow Patient.generalPractitioner (or Observation.subject)
 +
# search on patients
 +
# (advanced) Metadata driven interface (picklist?)
 +
 
  
 
==Scenarios==
 
==Scenarios==
<!-- What will be the actions performed by participants? -->
 
  
===Scenario Step 1 Name===
+
as implied by roles
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
  
<!-- Provide a description of each task -->
 
  
 
==TestScript(s)==
 
==TestScript(s)==
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.
+
 
These should be committed to SVN under trunk/connectathons/[connectathon]
+
Test scripts don't support graphQL yet. Should they?
-->
 
  
 
==Security and Privacy Considerations==
 
==Security and Privacy Considerations==
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
+
 
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
+
No implications not already obvious on the RESTful interface.
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
 
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.
 
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 
-->
 

Revision as of 06:03, 20 June 2017


GraphQL Track

Submitting WG/Project/Implementer Group

Grahame Grieve on behalf of FHIR-I/AID

Justification

There has been ongoing implementer interest in a more agile way to fetch data from a FHIR server, and some implementers have told me that they won't use FHIR because of this.

Proposed Track Lead

Grahame Grieve (looking for handover)

Expected participants

  • test.fhir.org
  • hapi server

Roles

Server

Makes data available through a graphQL interface:

  1. support query a patient resource using graphQL (or Observation)
  2. support forward reference - follow Patient.generalPractitioner (or Observation.subject)
  3. support search - allow search on patients
  4. support publish metadata describing 1-3

Servers should list which steps they implement on the tracking spreadsheets

Client

  1. query a patient resource using graphQL (or Observation)
  2. forward reference - follow Patient.generalPractitioner (or Observation.subject)
  3. search on patients
  4. (advanced) Metadata driven interface (picklist?)


Scenarios

as implied by roles


TestScript(s)

Test scripts don't support graphQL yet. Should they?

Security and Privacy Considerations

No implications not already obvious on the RESTful interface.