Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Track overview

Short Description

One of the 2020 Argonaut projects is Patient Lists, which enables a standardized way for software to access lists of patients which are commonly used in an EHR setting.

...

For example, "all patients in a location" or "all the patients on my schedule today."

Long Description

Gather early feedback from implementers on the Argonaut Patient Lists project.

Type

...

This track will cover some foundational, early-design operations such as list discovery, selecting list member records, and selection of "extra" patient data using various methods.

Long Description

User-facing apps often need to know things like:

  • “who are the patients I’m seeing today,”
  • “who are the patients I’m responsible for in the hospital right now,”
  • “who are the patients in this ward.”

This is core functionality supported by existing EHR systems.  In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource.  However, no standard or guidance for creation of, and manipulation of, patient lists currently exists.

Some project goals that will be addressed (and hopefully clarified with this connectathon experience):

  • Supporting interoperable and standard exchange of existing EHR supported “user-facing lists”.
    1. user-facing lists include both “system-maintained” and “user-maintained”(which are entirely ad-hoc - the user explicitly selects and manages members) lists
  • Defining a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.
  • API would allows user-facing apps to:
    • Search on existing list using very limited set of parameters such as “location characterstics” (for system-maintained lists) or Practitioner (for user-maintained list)
    • [? identify a “default list”]
    1. Discover user-facing lists
    2. Fetch the List, allowing app to enumerate members of a user-facing list
    3. Provide a framework to convey extra details about the members of a list

EHR vendors and third party software vendors wishing to use this new API are welcome to participate in this track.

Type

Test the design of a Resource/set of Resources

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

Argonaut

Proposed Track Lead

Carl Anderson, carl.anderson@microsoft.com

Related tracks

N/A

FHIR Version

...


FHIR v4.0.1

Specification(s) this track uses

...

The track spec is still under active development, so an existing reference is not yet available.  However, much of the relevant work and examples is present in this codelab exercise: https://

...

aka.

...

ms/

...

patient-lists

...

https://hackmd.io/AfJ9YNb6TNGeDSuAaHIn1g?view

Artifacts of focus

-codelab 

Further project-management information may be useful to interested parties and can be found here:

Clinical input requested (if any)

We're running with a handful of example patient lists, such as "all the patients in a location" and "all the patients a provider will see in a day / week" - but if there are other more relevant lists, suggestions from clinicians are welcome.

It has also been suggested that once a list of patients has been identified for selection, there may be relevant pieces of information that are not directly attached to the patient record, such as:

  • date of the most recent encounter
  • admit date
  • scheduled discharge date
  • last provider to visit the patient
  • current room number
  • etc

Any insight into other relevant data points that may be useful when working with patient lists will be most welcome by track participants.

Patient input requested (if any)

Same as above - if there are any well established places where lists of patients are frequently used or useful, patient/caretaker input is welcome.

Expected participants

Server Implementers: Epic, Cerner, Meditech, PeraHealth?, ...

Zulip stream

https://chat.fhir.org/#narrow/stream/227046-Argo-Patient.20Lists

Track Orientation

...

TBD - likely to be pre-recorded in late August and released very early in September.

Track details

System Roles

Server implementers (EHR vendors) and clients (third-party software vendors) are both welcome.

Scenarios

A

...

Server Developers

Scenarios

Server Passes Capability Checks

Action: An open source tool examines a participant server, confirming that it advertises capabilities correctly and passes a simple smoke test.

Precondition: A group is defined in the participant server in such a way that the smoke test will pass (details TBD).

Success Criteria: The server capabilities suggest patient lists are supported and the smoke test passes.

Bonus point:

Client Software Developers

Scenarios

Software Displays an Example Patient List from FHIR Server

Action: Participant is able to connect to a FHIR Server and retrieve a patient list, rendering it in their app.

Precondition: A group is defined in a provided FHIR Server in such a way that any participant can read it.

Success Criteria: The client renders the complete patient list.

Bonus point: Correct pagination is handled, as well as any other relevant details that may need to be gathered by invoking other queries against the server (for example, data related to the most recent encounter).

FHIR Server includes additional "columns" in patient list

Action: FHIR Server returns Group resource with an extension referencing a Questionnaire resource, and an extension referencing a QuestionnaireResponse resource per patient

Precondition: A group is defined in a provided FHIR Server in such a way that any participant can read it. Questionnaire exists which defines additional list columns.

Success Criteria: The client parses extensions.

Bonus point: Client validates questionnaireresponses against questionnairedockerized HAPI server will be provided that is populated with a canonical set of Synthea-generated FHIR data.  This server image, and the scripts used to generate it, will be made available both to server implementers and third party vendors for testing purposes prior to the connectathon.  Instructions will be provided in github and in the introductory video.  

A script will also be made available that can generate the Synthea data and load it into an empty server, which will be useful for the server implementer participants.  Instructions to BYOS (bring your own server) will be made available.

The IDs mentioned in the scenarios below are subject to change as the canonical data is developed.

As a side note, all of these scenarios below assume that the server supports, and the client specifies, the _summary search parameter in queries for patient list Groups from the server.

1 - Patient List Discovery

A server is able to produce a list of the available Patient Lists known.  A client is able to render a list of known Patient Lists.

Action: A client issues a GET request to a server:

        GET Group?_summary=true&type=person

Server Success Criteria: The server responds with a complete Bundle of the available Group entries with type person.

Client Success Criteria: The list of lists is rendered in HTML.

2 - Organization-Managed Lists

A server is able to provide a collection of patient lists that are managed by a particular organization.  A client is able to query for lists, specifying the managing Organization in the request.

Action: A client issues a GET request to a server:

        GET Group?_summary=true&type=person&managingEntity=Organization/42

Server Success Criteria: The server responds with a Bundle of Group entries where each entry is managed by an Organization with an ID of '42'.

Client Success Criteria: The client provides a selector listing available Organizations.  When selected, a query returns the patient lists that are managed by the selected Organization.

3 - Patient Lists Members

A server is able to produce the Patient entries of a patient list.  A client is able to render the list of patients using Patient-level resource attributes.

Action: A client issues a GET request to a server:

        GET Group/123

Server Success Criteria: The server responds with a complete Bundle of Patient entries, all members of the requested Group with ID '123'.

Client Success Criteria: The client queries for a particular list of patients and then renders in HTML those patients, including Patient-level resource attributes such as Name, Age, DOB, Gender, Height, Weight, etc.

4 - Patient Lists - Extra Details via RESTful API

When requested, a server provides patient details that are not present in the patient resource directly.

Action: A client issues a GET request, fetching a patient list.  Then, for each patient in the list, an Observation attribute (the most recent lab result) is requested, which is not directly part of the patient resource.

        GET Group/123
for each patient in group123.bundle.entry:
GET Observation/$lastn?patient=Patient/$ID&category=laboratory

Server Success Criteria: The client bundles the Observation GET requests in a request Bundle, sending a minimum number of GET requests to the server.

Client Success Criteria: The request bundle is properly prepared, minimizing GET operations against the server.  All fetched 'extra details' are then also displayed in output HTML.

5 - Patient Lists - Extra Details via Questionnaire

When requested, a server provides patient details that are not present in the patient resource directly via a Questionnaire and QuestionnaireResponse method.

Action: A client issues a GET request, fetching a patient list.  Then, for each patient in the list, an Observation attribute (the most recent lab result) is requested, which is not directly part of the patient resource, but is provided by a pre-made Quesionnaire that is capable of delivering the desired attributes through a QuestionnaireResponse invocation.

        GET Group/123
TODO: identify how the appropriate questionnaire is determined from the group
for each patient in group123.bundle.entry:
  TODO: insert an apt GET operation to be included in the request bundle

Server Success Criteria: The requested patient attributes are returned in a QuestionnaireResponse resource entry of a bundle.

Client Success Criteria: The client bundles the Observation GET requests in a request Bundle, sending a minimum number of GET requests to the server.  All extra patient details are extracted from a QuestionnaireResponse resource.

TestScript(s)

The test scripts for server developers are still a work in progress, but the clients developers can configure their software to connect to a provided FHIR Server.

Security and Privacy Considerations

N/A