Apply Appropriate Data Models in Cosmos DB for NoSQL

Refer to the link in the Additional Information and Resources section of the lab to download a one-page document describing the datasets you are going to work with in this objective. The document applies to both objectives of the lab.

Usage Scenario:

Your company supports a microservice for a larger medical office management application that alerts a primary care provider (PCP) when one of their patients have been admitted to the hospital. For your microservice, you will take a subset from each of the three datasets described and store the subset of data in one or more Cosmos DB for NoSQL database containers. The ADT dataset is available as a near real-time stream to your Cosmos DB containers. Primary care provider data is only updated when a primary care physician joins or leaves a practice. The subset of patient demographic data is synced daily from the centralized database; only data needed by the microservice to match patients with the stream of ADT events is stored.

The first step in the design process is to list the participating entities. In this microservice, you care about the following entities:

ADT: Encounter, Facility, Patient

Provider: Provider (only a small list that rarely changes, filtered by the primary care providers and managed by your application users)

Patient: Person

Access Patterns:

• Humans will typically not be writing or querying any of this data.
• The system matches the ADT Patient entity to the Person entity using the InsuranceID, and alerts the PCP Provider entity to the Person, the Encounter, and the Facility location.

Questions to Answer:

• How many containers do you need?
• Which entities will stand alone and which will be nested within another?
• For each container, what is the best partition key to avoid hot partitions, while serving access patterns?

Options for This Scenario:

A) Two containers. 1) An ADT container that stores the Encounter with the Facility and Patient each nested within it. The partition key is InsuranceID. 2) A PCP container with the Provider entity and the Person entity as separate documents, and with an Entity_Type property added to both entities. PCP_NPI is the partition key.

B) Three containers. 1) An ADT container that stores the Encounter with the Facility and Patient nested within it. The partition key is EncounterID. 2) A Provider container with the Provider entity. NPI is the partition key. 3) A Patient container with the Person entity. PatientID is the partition key.

C) Two containers. 1) An ADT container that stores the Encounter with the Facility and Patient nested within it. The partition key is Encounter_StartDateTimeStamp. 2) A PCP container with the Provider with each Person entity object nested under a property called Patients. NPI is the partition key.

Apply Your Design

Choose the best option and create the containers with the designated partition key in the LabDB database.

Usage Scenario:

Your company supports a microservice of a larger medical office management application that encourages practice nurses to log high-value follow-up calls to patients who have recently received surgery, outpatient procedures, or other encounters that require continuing care. The purpose is partly medical and partly customer service. The follow-up calls are intended to provide good, ongoing medical care but also to help patients feel confident and comfortable in choosing the provider clinic.

The microservice records the call and provides the nurse with key elements of the encounter — without the bulk and clutter of the full medical office management system. They have just the data they need, presented in a simple UI, to conduct the call efficiently. This allows them to focus on the customer service or "bedside manner" portions of the conversation. As the conversation goes on, the nurse can click on key metadata that coincides with what's being spoken. The logged call is ultimately fed into a natural language processor and AI engine to perform sentiment analysis and measure the quality of the telephone call. The processed output becomes its own medical encounter attached to the patient record. At the end of the call, the nurse uses the metadata to compose notes and populate a next-steps list for further follow up.

The microservice will take a subset from each of the three datasets described and store the subset of data in one or more Cosmos DB for NoSQL database containers. The ADT dataset is available as a near real-time stream to your Cosmos DB containers. Provider data in Cosmos is only updated monthly when the source data set is refreshed. The subset of patient demographic data stored in a Cosmos DB container is synced daily from the centralized database. In all cases, only data needed to match the patient with the encounter (in the case of encounters from the ADT data) and data to conduct the phone call is stored.

The first step in the design process is to list the participating entities. In this micro-service, you care about the following entities:

ADT: Encounter, Patient

Provider: Provider

Patient: Person, Encounter

Access Patterns:

• The microservice will read from the containers using queries.
• The UI presents essential data to the nurse. When the call connects, the nurse clicks to create a new encounter, which is cached, and not yet written to the database.
• Typically, the nurse can conduct the call with just the key information about the encounter they are calling about. However, if necessary, they can browse other encounters associated with the patient.
• The UI cannot update any of the original patient, provider, or encounter data, so if the patient mentions a change to their information is needed, the nurse adds that to the notes associated with the encounter and clicks a flag that will send an alert to the medical office management system (which is handled by another microservice outside of the scope of this scenario.)
• At the end of the call, The microservice stores the audio in blob storage and returns a reference to the application — still, only cached at this point.
• The nurse completes their encounter notes and the UI writes the metadata, notes, and reference to the blob storage location to a new encounter object in Cosmos DB.
• Each night, when the patient data is synced from the main database, the new encounter (the phone call with notes) is written back to the main database.

Questions to Answer:

• How many containers do you need?
• Which entities will stand alone and which will be nested within another?
• For each container, what is the best partition key to avoid hot partitions, while serving access patterns? Note: In all cases, the original Encounter object will source from either ADT stream or from the Patient data maintained by the medical office management system.

Options for This Scenario:

A) Two containers. 1) A PatientEncounters container that stores the Person, with the original Encounter nested under the Person, and the new telephone encounter also written and nested under the original Encounter. Up to three provider NPIs and names are nested within the Encounter objects. The partition key is PatientID. 2) An Encounters container with all of each patient's prior encounters stored individually. PatientID is the partition key.

B) Three containers. 1) A Person container that stores the patient's Person data. The partition key is PatientID. 2) A Provider container with the Provider entity. NPI is the partition key. 3) A Patients container with the Person entity. PatientID is the partition key.

C) One container. 1) Two document types: A PatientEncounters container that stores the Person, with the original Encounter nested under the Person. And another document type that stores each historical Encounter for the patient. The new telephone encounter is written to a document of this type. Up to three provider NPIs and names are nested within the Encounter objects with the two separate documents, you will need to add an Entity_Type property to both entities. The partition key is PatientID.

Apply Your Design

Choose the best option and create the containers with the designated partition key in the LabDB database.