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

Difference between revisions of "201805 Clinical Notes Track"

From HL7Wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by 3 users not shown)
Line 39: Line 39:
 
Servers: Epic, Cerner. Plan to contact Argonaut organizations for additional participants.  
 
Servers: Epic, Cerner. Plan to contact Argonaut organizations for additional participants.  
  
 +
Clients: Postman to start
  
−
Clients: TBD
+
[https://docs.google.com/spreadsheets/d/15NwlqqUP2D95Z6XN5IJoOFDjyGlT7ZgU71dvromgqIY/edit#gid=1931673721 Sign-up Sheet!]
  
 
==Roles==
 
==Roles==
Line 52: Line 53:
 
A Server that contains Clinical Data.
 
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.
  
−
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 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.
 +
 
 +
EHRs (servers) may return a Note using binary in a variety of formats:
 +
*ASCII
 +
*XHTML
 +
*RTF or PDF
 +
*Mixed document - structured information and narrative (CDA).  
 +
 
 +
Access to a Clinical Note is a two step process for the client:
 +
# Search and retrieve the DocumentReference
 +
# Retrive the Note (Binary or Composition)
  
−
==Scenarios==
+
Requesters (clients) should be capable, at minimum, of displaying each format.
−
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.
+
 
 +
During the development of the track we discussed directly embedding content in the DocumentReference.content.attachment.data but no server planned to support in this connectathon so decided to save for the future.
  
−
A typical EHR may have hundreds of different Note types. For testing, this track will focus on three broad categories, and formats:
+
This track also includes one scenario for a Client to create (write) a note to the server. In this use cases the client embeds the base64 content directly in DocumentReference.content.attachment.data for the server to store.
−
*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)
 
−
*Additional Note Types - 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:
+
=== 1. Retrieve an Encounter Summary Note with DocumentReference id===
−
*ASCII or XHTML
+
:Action: A patient or provider requester (client) previously cached a DocumentReference id retrieves the note. The EHR (server) returns a DocumentReference with a pointer to a the Clinical Note (binary) for the client to retrieve.
−
*RTF or PDF -
+
:Precondition:  There is a DocumentReference with a pointer to a valid Binary resource
−
*Mixed document  - structured information and narrative (Composition, CDA).  
+
:Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (Binary Resource).
  
−
In each case, the content may be embedded directly in DocumentReference.Attachment.data or as reference to a Binary resource.
+
GET [base]/DocumentReference/[id]
 +
Using the information in DocumentReference.content.attachment.url
 +
GET [base]/Binary/[id]
  
−
Requesters (clients) should be capable, at minimum, of displaying each format.  
+
=== 2. Retrieve all notes by patient===
 +
:Action: A patient or provider requester (client) queries for all Clinical Notes for a patient. The EHR (server) returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
 +
:Precondition:  There is a DocumentReference with a valid patient and pointer to a valid binary
 +
:Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (binary).
  
−
=== 1. Retrieve an Encounter Summary Note ===
+
GET [base]/DocumentReference?patient=[id]
−
: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.
+
GET [base]/Binary/[id]
−
:Precondition: There is a patient and note in the system.
+
Example:
−
:Success Criteria: Clinical Note is returned and displayed in interface.
+
  GET [base]/DocumentReference?patient=1316024
−
: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]
+
=== 3. Retrieve a Patient's Notes by Searching with a Date Range===
−
  GET [base]/DocumentReference?patient=1234&type=http://loinc.org | 8648-8
+
:Action: A patient or provider requester (client) queries for all Clinical Notes for a patient created after a certain date. The EHR (server) returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
 +
:Precondition: There is a DocumentReference with a valid patient and pointer to a valid binary
 +
:Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (binary).
  
−
=== 2. Retrieve a Diagnostic Report ===
+
GET [base]/DocumentReference?patient=[id]&created=[date]
−
: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.
+
GET [base]/Binary/[id]
−
:Precondition: There is a patient and note in the system.
+
Example:
−
:Success Criteria: Clinical Note is returned and displayed in interface.
+
  GET [base]/DocumentReference?patient=1316024&created=ge2018-04-11
−
: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
+
=== 4. Retrieve a Patient's Discharge Summary Notes ===
 +
:Action: A patient or provider requester (client) queries for all patient Discharge Summary Notes. The EHR (server) returns returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
 +
:Precondition: There is a patient and note classified as Discharge Summary is in the system.
 +
:Success Criteria: Clinical Note is returned and displayed in interface.
  
−
=== 3. Retrieve a Specialty Note ===
+
GET [base]/DocumentReference?patient=[id]&type=[note type (LOINC)]
−
: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.
+
GET [base]/Binary/[id]
−
:Precondition: There is a patient and note in the system.
+
Example:
−
:Success Criteria: Clinical Note is returned and displayed in interface.  
+
  <pre>GET [base]/DocumentReference?patient=1316024&type=http://loinc.org|8648-8</pre>
−
: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
+
=== 5. Write a new note to a Patient's Chart ===
 +
:Action: A patient or provider (client) commits a new note to a FHIR server. The EHR (server) stores the note for future retrieval.
 +
:Precondition: FHIR server is capable of receiving a DocumentReference with content embedded in DocumentReference.content.attachment.data and split into DocumentReference and Binary on storage
 +
:Success Criteria: Client is able to retrieve Clinical Note
  
−
=== 4. Write using DocumentReference and Binary ===
+
POST [base]/DocumentReference
−
This scenario will cover two parts:
+
Example:
−
  1. DocumentReference with Binary to write to a server.  
+
POST [base]/DocumentReference
−
2. DocumentReference with data directly in attachment data type.
+
Request Headers:
 +
  content-type: "application/json"
 +
  prefer: "return=REPRESENTATION"
 +
  accept: "application/fhir+json"
 +
  Request Body:
 +
  {
 +
    "resourceType": "DocumentReference",
 +
    "type": {
 +
        "coding": [
 +
            {
 +
                "system": "http://loinc.org",
 +
                "code": "8648-8",
 +
                "display": "Discharge Summary"
 +
            }
 +
        ],
 +
        "text": "Discharge Summary"
 +
    },
 +
    "subject": {
 +
        "reference": "[base]/Patient/eso2MXsmcJloTEUEls5DzbA3"
 +
    },
 +
    "content": [{"attachment": {
 +
        "contentType": "text/plain",
 +
        "data": "Tm8gYWN0aXZpdHkgcmVzdHJpY3Rpb24sIHJlZ3VsYXIgZGlldCwgZm9sbG93IHVwIGluIHR3byB0byB0aHJlZSB3ZWVrcyB3aXRoIHByaW1hcnkgY2FyZSBwcm92aWRlci4="
 +
    } }],
 +
    "context": {"encounter": {"reference": "[base]/Encounter/eIOY6XJQw0hvmvCqTtkg6vQ3"} }
 +
  }
  
 
==TestScript(s)==
 
==TestScript(s)==

Latest revision as of 07:11, 12 May 2018

Return to May 2018 Proposals

Zulip Chat stream for this Track is here and issues can be posted here

Background For Clinical Notes

Clinical Notes are a critical element for clinicians to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, ASCII), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). Common clinical notes as identified by the Argonaut participants:

  • Discharge documentation (8648-8 and/or 18842-5)
  • Consultation (11488-4)
  • Imaging narrative (18726-0)
  • Lab/path narrative
  • History & Physical (34117-2)
  • Progress note
  • Procedures note (28570-0)

Many others …Transfer note, Referral note, Surgical Operation note, Nurse note. This track will explore a limited set with the intention it will cover other note types..

The current FHIR STU3, and ballot version of FHIR STU4, does not include concrete guidance for exchanging notes. Various work groups within HL7 have considered DocumentReference, Observation, Composition, DiagnosticReport, or a brand new resource. After discussions at the January 2018 during the Connectathon, and subsequently in the HL7 working group Patient Care the initial, the consensus was to proceed with a connectathon track to test out a few different Resources. This track will test use of the DocumentReference and DiagnosticReport to exchange Clinical Notes. A draft Argonaut Clinical Notes Profile will be available middle of April. It is based upon the FHIR 3.0.1 Standard.

Submitting WG/Project/Implementer Group

The Argonaut Project

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, and DiagnosticReport resources.

The US ONC released a draft U.S. Core Data for Interoperability as a part of TEFCA 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: Postman to start

Sign-up Sheet!

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 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.

EHRs (servers) may return a Note using binary in a variety of formats:

  • ASCII
  • XHTML
  • RTF or PDF
  • Mixed document - structured information and narrative (CDA).

Access to a Clinical Note is a two step process for the client:

  1. Search and retrieve the DocumentReference
  2. Retrive the Note (Binary or Composition)

Requesters (clients) should be capable, at minimum, of displaying each format.

During the development of the track we discussed directly embedding content in the DocumentReference.content.attachment.data but no server planned to support in this connectathon so decided to save for the future.

This track also includes one scenario for a Client to create (write) a note to the server. In this use cases the client embeds the base64 content directly in DocumentReference.content.attachment.data for the server to store.

1. Retrieve an Encounter Summary Note with DocumentReference id

Action: A patient or provider requester (client) previously cached a DocumentReference id retrieves the note. The EHR (server) returns a DocumentReference with a pointer to a the Clinical Note (binary) for the client to retrieve.
Precondition: There is a DocumentReference with a pointer to a valid Binary resource
Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (Binary Resource).
GET [base]/DocumentReference/[id]

Using the information in DocumentReference.content.attachment.url 

GET [base]/Binary/[id]

2. Retrieve all notes by patient

Action: A patient or provider requester (client) queries for all Clinical Notes for a patient. The EHR (server) returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
Precondition: There is a DocumentReference with a valid patient and pointer to a valid binary
Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (binary).
GET [base]/DocumentReference?patient=[id]
GET [base]/Binary/[id]

Example: 

GET [base]/DocumentReference?patient=1316024

3. Retrieve a Patient's Notes by Searching with a Date Range

Action: A patient or provider requester (client) queries for all Clinical Notes for a patient created after a certain date. The EHR (server) returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
Precondition: There is a DocumentReference with a valid patient and pointer to a valid binary
Success Criteria: Server returns pointer to binary. Client is able to retrieve and display Clinical Note (binary).
GET [base]/DocumentReference?patient=[id]&created=[date]
GET [base]/Binary/[id]

Example: 

GET [base]/DocumentReference?patient=1316024&created=ge2018-04-11

4. Retrieve a Patient's Discharge Summary Notes

Action: A patient or provider requester (client) queries for all patient Discharge Summary Notes. The EHR (server) returns returns one or more DocumentReference Resources with a pointer to the Clinical Notes (binary) for the client to retrieve.
Precondition: There is a patient and note classified as Discharge Summary is in the system.
Success Criteria: Clinical Note is returned and displayed in interface.
GET [base]/DocumentReference?patient=[id]&type=[note type (LOINC)]
GET [base]/Binary/[id]

Example: 

GET [base]/DocumentReference?patient=1316024&type=http://loinc.org|8648-8

5. Write a new note to a Patient's Chart

Action: A patient or provider (client) commits a new note to a FHIR server. The EHR (server) stores the note for future retrieval.
Precondition: FHIR server is capable of receiving a DocumentReference with content embedded in DocumentReference.content.attachment.data and split into DocumentReference and Binary on storage
Success Criteria: Client is able to retrieve Clinical Note
POST [base]/DocumentReference

Example: 

POST [base]/DocumentReference
Request Headers:
 content-type: "application/json"
 prefer: "return=REPRESENTATION"
 accept: "application/fhir+json"
Request Body:
 {
   "resourceType": "DocumentReference",
   "type": {
       "coding": [
           {
               "system": "http://loinc.org",
               "code": "8648-8",
               "display": "Discharge Summary"
           }
       ],
       "text": "Discharge Summary"
   },
   "subject": {
       "reference": "[base]/Patient/eso2MXsmcJloTEUEls5DzbA3"
   },
   "content": [{"attachment": {
       "contentType": "text/plain",
       "data": "Tm8gYWN0aXZpdHkgcmVzdHJpY3Rpb24sIHJlZ3VsYXIgZGlldCwgZm9sbG93IHVwIGluIHR3byB0byB0aHJlZSB3ZWVrcyB3aXRoIHByaW1hcnkgY2FyZSBwcm92aWRlci4="
   } }],
   "context": {"encounter": {"reference": "[base]/Encounter/eIOY6XJQw0hvmvCqTtkg6vQ3"} }
 }

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)
Retrieved from "https://wiki.hl7.org/w/index.php?title=201805_Clinical_Notes_Track&oldid=156906"