|
|
| Line 1: |
Line 1: |
| − | | + | This was accidentally created, should have been Patient Match |
| − | [[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]]
| |
| − | __NOTOC__
| |
| − | =Patient Match=
| |
| − | | |
| − | ==Submitting WG/Project/Implementer Group==
| |
| − | Patient Administration
| |
| − | | |
| − | ==Justification==
| |
| − | The Patient Match operation was updated in STU3, and implementation experience on this new definition is desired prior to going Normative in R4
| |
| − | | |
| − | ==Proposed Track Lead==
| |
| − | Brian Postlethwaite (skype: sgtshultzpos email: brian_pos at hotmail dot com)
| |
| − | | |
| − | ==Expected participants==
| |
| − | * Telstra Health
| |
| − | | |
| − | ==Roles==
| |
| − | ===Patient Match Server===
| |
| − | A server that implements the $match operation
| |
| − | | |
| − | ===Patient Match Client===
| |
| − | A client application that is able to call the match operation and view/process the results (including the weightings if included)
| |
| − | | |
| − | ==Scenarios==
| |
| − | <!-- What will be the actions performed by participants? -->
| |
| − | | |
| − | ===Scenario Step 1 Name===
| |
| − | :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)==
| |
| − | <!-- 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]
| |
| − | -->
| |
| − | | |
| − | ==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.
| |
| − | * 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
| |
| − | -->
| |
