Difference between revisions of "201805 Clinical Notes Track"
Bamarquard (talk | contribs) |
Bamarquard (talk | contribs) |
||
| Line 82: | Line 82: | ||
GET [base]/DocumentReference?patient=1234&type=http://loinc.org | 18726-0 | GET [base]/DocumentReference?patient=1234&type=http://loinc.org | 18726-0 | ||
| − | === 3. Retrieve a | + | === 3. Retrieve a Speciality Note === |
| − | :Action: A patient or provider requester (client) queries for a Progress Note associated with an encounter. The EHR (server) may return the note or a pointer to retrieve the note. | + | :Action: A patient or provider requester (client) queries for a Cardiology Progress Note associated with an encounter. The EHR (server) may return the note or a pointer to retrieve the note. |
:Precondition: There is a patient and note in the system. | :Precondition: There is a patient and note in the system. | ||
:Success Criteria: Clinical Note is returned and displayed in interface. | :Success Criteria: Clinical Note is returned and displayed in interface. | ||
Revision as of 15:23, 20 March 2018
Zulip Chat stream for this Track is here and issues can be posted here
Background For Clinical Notes
This track is based upon Argonaut Clinical Notes Profile. It is based upon the FHIR 3.0.1 Standard.
For additional background, review the DocumentReference resource.
Submitting WG/Project/Implementer Group
Justification
The Argonaut Clinical Notes Profile is a vendor agnostic specification providing FHIR RESTful APIs and guidance for access to Clinical Notes by both patient and practitioner end users. This specification is based on FHIR Version 3.0.1 and specifically the DocumentReference resource.
The US ONC released a draft U.S. Core Data for Interoperability which proposed support for Clinical Notes access.
Proposed Track Lead
Coordinator: Brett Marquard
Expected participants
Servers: Epic, Cerner. Plan to contact Argonaut organizations for additional participants.
Clients: TBD
Roles
Provider or 3rd Party consumer application (Client)
An application that should be used by an end user (e.g., patient or practitioner) to support search for and retrieval of Clinical Notes.
FHIR Server (EHR)
A Server that contains Clinical Data.
If creating a client application, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required.
Scenarios
This track will test a patient and provider access to Clinical Notes. Patient so that they are better informed and able to make important decisions about their health. Providers so that the continuity of care is maintained across multiple settings and healthcare workers.
A typical EHR may have hundreds of different Note types. For testing, this track will focus on three broad categories, and formats:
- Encounter Summary Notes - information covering the entire encounter (Discharge Summary, H&P, Consultation, Transfer note Referral note)
- Diagnostic Reports - supporting an order (Procedure, Lab/Pathology, Imaging)
- 'Sub-encounter' Notes - Occurs within an encounter but doesn’t summarize the encounter (Nurse note, Progress Note, Procedure note, Surgical Operation note)
EHRs (servers) may return a Note in a variety of formats:
- ASCII or XHTML
- RTF or PDF -
- Mixed document - structured information and narrative (Composition, CDA).
In each case, the content may be embedded directly in DocumentReference.Attachment.data or as reference to a Binary resource.
Requesters (clients) should be capable, at minimum, of displaying each format.
1. Retrieve an Encounter Summary Note
- Action: A patient or provider requester (client) queries for a Discharge Summary Note. The EHR (server) may return the note or a pointer to retrieve the note.
- Precondition: There is a patient and note in the system.
- Success Criteria: Clinical Note is returned and displayed in interface.
- Bonus point: The Server supports multiple versions and Clients can query and display previous versions of the Note
GET [base]/DocumentReference?patient=[id]&type=[type] GET [base]/DocumentReference?patient=1234&type=http://loinc.org | 11488-4
2. Retrieve a Diagnostic Report
- Action: A patient or provider requester (client) queries for an Imaging report. The EHR (server) may return the note or a pointer to retrieve the note.
- Precondition: There is a patient and note in the system.
- Success Criteria: Clinical Note is returned and displayed in interface.
- Bonus point: The Server supports multiple versions and Clients can query and display previous versions of the Note
GET [base]/DocumentReference?patient=1234&type=http://loinc.org | 18726-0
3. Retrieve a Speciality Note
- Action: A patient or provider requester (client) queries for a Cardiology Progress Note associated with an encounter. The EHR (server) may return the note or a pointer to retrieve the note.
- Precondition: There is a patient and note in the system.
- Success Criteria: Clinical Note is returned and displayed in interface.
- Bonus point: The Server supports multiple versions and Clients can query and display previous versions of the Note
GET [base]/DocumentReference?encounter=1234&type=http://loinc.org | 11506-3 <-- need to double check
TestScript(s)
The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at: TBD
Please note that the available TestScripts test the TBD
Security and Privacy Considerations
- 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), is out of scope and left to implementations. Expectation is many systems will use SMART on FHIR (OAuth)
