|
|
| Line 1: |
Line 1: |
| | | | |
| − | [[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]]
| |
| − | __NOTOC__
| |
| − | =Electronic Case Reporting=
| |
| − |
| |
| − | ==Submitting WG/Project/Implementer Group==
| |
| − | Public Health (PH)
| |
| − |
| |
| − | ==Justification==
| |
| − | Electronic case reporting has been maturing in the CDA product family, and FHIR case reporting specifications are now also being being developed. This track will explore various aspects of FHIR case reporting as they mature, beginning with trigger code representation and dissemination, expanding to decision support logic and other transactions to support case reporting and management as those aspects mature in future Connectathons. This track could include discussions on additional resource needs for these use cases.
| |
| − |
| |
| − | ==Proposed Track Lead==
| |
| − | * John Loonsk
| |
| − | * Rick Geimer
| |
| − |
| |
| − |
| |
| − | See [[Connectathon_Track_Lead_Responsibilities]]
| |
| − |
| |
| − | ==Expected participants==
| |
| − | * APHL
| |
| − | * CDC
| |
| − | * CGI Federal
| |
| − | * Epic
| |
| − | * Lantana Consulting Group
| |
| − |
| |
| − | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
| |
| − |
| |
| − | ==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 -->
| |
| − | ===Public Health===
| |
| − |
| |
| − | Responsible for managing and disseminating trigger codes and decision logic.
| |
| − |
| |
| − | ===Public Health Agency===
| |
| − |
| |
| − | Jurisdiction or agency that will receive and manage case reports, and at times send and/or receive reportability responses.
| |
| − |
| |
| − | ===Intermediaries===
| |
| − |
| |
| − | Organizations in the information flow between a health care organization and a public health agency. Examples include HIEs, the shared platform supported by APHL and CSTE, etc.
| |
| − |
| |
| − | ===Health Care Organization===
| |
| − |
| |
| − | Organization that submits case reports based on trigger codes, and receives trigger code updates and reportability responses. The health care organization can be supported by an EHR vendor in this role.
| |
| − |
| |
| − | ==Scenarios==
| |
| − | <!-- What will be the actions performed by participants? -->
| |
| − |
| |
| − | === Update Trigger Codes on Public Health FHIR Server ===
| |
| − | :Action: Public Health determines that the current trigger code value sets require an update. The appropriate value sets are updated using PUT. Also update trigger codes as a Bundle of ValueSet resources so they can be updated as a whole set.
| |
| − | :Precondition: Original trigger code value sets exist on test server
| |
| − | :Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET
| |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
| |
| − |
| |
| − | === Subscribe to Trigger Code Updates ===
| |
| − | :Action: Provider organization uses Subscription to subscribe to changes to trigger code value sets (or value set Bundle) using any legal notification method.
| |
| − | :Precondition: Original trigger code value sets exist on test server
| |
| − | :Success Criteria: Provider organization is notified and receives a copy of any trigger code value sets that are updated
| |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
| |
| − |
| |
| − | === Ingest Trigger Codes into EHR ===
| |
| − | :Action: Provider organization receives a trigger code update, and ingests the trigger codes into their EHR to support case report initiation.
| |
| − | :Precondition: Trigger codes updates have been received by provider organization
| |
| − | :Success Criteria: Trigger code updates successfully ingested into EHR
| |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
| |
| − |
| |
| − | ==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
| |
| − | -->
| |
