Page Comparison

Context

Shared Health Record (SHR) serves as a repository containing clinical care information for patients. SHR houses subset of data from various EMRs from different care delivery organisations. This record is shared between different institutions and systems. For patients, such information are represented as Encounters in SHR. Each such encounter information therein is stored as a FHIR resource document.

FHIR encounter – is a resource that mainly has administrative information, for example contact with patient with date, participants etc. Whereas in medical domain, encounter is more holistic, that includes clinical information gathered for patients, drugs/tests advised, observations/diagnoses done etc.

Lets take an example of an outpatient consultation of a doctor with a patient -doctor meetup where patients mentioned “Hypertension” as chief complaint, and doctor has done some physical examination (e.g. Blood Pressure), advised some medication and noted down preliminary diagnoses for the patientwhere the patient is diagnosed with presumed “Influenza”, and doctor also noted down (after physical examination) her temperature readings.

The EMR sytsem at the Facility would communicate all the facts with SHR by means of a “document”, formed to provide coherent context for an “Encounter” information. The context description of an encounter can be modeled using a FHIR resource "Bundle".

In our context, this "bundle" is basically a collection of other FHIR resources. The most important resource within the bundle is “Composition”, that organizes/bundles other resources relevant to the clinical encounter within the document. Following is the basic structure

Basic Structure

A Composition resource will have

identifier - usually an unique id within the document
date - the date of editing the composition
status - the workflow status of the composition (final, preliminary etc) - usually final in our case.
subject - reference to the patient. This is the complete URL reference to the patient
encounter - references to the administrative encounter resource contained within the same document
List of sections - this are other FHIR resources that form the facts within the encounter. Usually these are internal references to the other entry resources in the same document.

The document will have references to existing and new resources. Existing resources include Patient, practitioner (provider) and some clinical resources like condition, medication & tests. In FHIR terms, we will have internal and external resource references in the document. See here for resource references.

Composition

For detailed information of definition of composition (attributes), see here

<Composition xmlns="http://hl7.org/fhir">
   <identifier>
     <value value="urn:12fafd36-20f7-4f88-8721-9a4a31fbeacf"/>
   </identifier>
   <date value="2015-01-07T12:00:15+05:30"/>
   <status value="final"/>
   <subject>
     <reference value="http://mci.twhosted.com/api/v1/patients/5893922485019082753"/>
     <display value="Monika Ramesh"/>
   </subject>
   <encounter>
     <reference value="urn:07f02524-7647-43c1-a579-0c2c80f285ed"/>
     <display value="Encounter"/>
   </encounter>
   <section>
     <content>
        <reference value="urn:40b43d8a-b582-4080-8c04-93697b82a795"/>
        <display value="Temperature"/>
     </content>
   </section>
   <section>
     <content>
        <reference value="urn:e45dbdca-4e39-4a79-b1b8-fd622fdff6e3"/>
        <display value="Diagnosis"/>
     </content>
   </section>
 </Composition>

Encounter

Encounter happens between Practitioner/care-provider and a patient. The encounter snippet shown below is FHIR encounter, which captures the administrative information for workflow management. For SHR, the entire composition resource is the clinical "Encounter" the API serves.

{
"resourceType": "Encounter",
"text": {
    "status": "generated",
    "div": "Encounter with patient BD1001"
},
"status": "finished",
"class": "outpatient",
"subject": {
    "reference": "Patient/example"
},
"participant": [
    {
      "individual": {
        "reference": "http://providers.twhosted.com/D101"
      }
    }
],
"serviceProvider" : { },
"identifier" : [{}],
"type" : {}
}

the clinical "Encounter" the API serves.

<Encounter xmlns="http://hl7.org/fhir">
   <identifier>
      <value value="urn:07f02524-7647-43c1-a579-0c2c80f285ed"/>
   </identifier>
   <status value="finished"/>
   <class value="outpatient"/>
   <type>
      <text value="outpatient"/>
   </type>
   <subject>
      <reference value="http://mci.twhosted.com/api/v1/patients/5893922485019082753"/>
      <display value="Monika Ramesh"/>
   </subject>
   <participant>
      <individual>
        <reference value="http://pr.twhosted.com/providers/18.json"/>
        <display value="Dr. Azad"/>
      </individual>
   </participant>
</Encounter>

Where

class: classification - inpatient | outpatient | ambulatory | emergency | home | field | daytime | virtual
status: planned | in progress | onleave | finished | cancelled.
type: 0..*. Specifies type of encounter. e.g. consultation, surgical day-care, rehab etc. We will have to define a coded set for this. TBD.
participant: 0..*. Specifies care providers in this encounter. For example, in a surgery, there maybe multiple providers of different type.
serviceProvider: identifies the facility or community health clinicidentifier: local identifier in HMIS
identifier: local identifier in HMIS
subject - reference to the patient. This is the complete URL reference to the patient

NOTE: there are many other attributes of FHIR encounter (like hospitalization, location etc). They maybe included as we see use cases.

Important to note, how the encounter links with the composition resource described above. The composition resource above references the encounter resource within the same document using the same reference id.

Now, lets see how the temperate reading is recorded as "observation", and diagnosis (influenza) as "condition".

Diagnosis

Diagnosis is captured through FHIR condition, with "category" as "Diagnosis".

{
  "resourceType": "Condition",
  "text": {
    "status": "generated",
    "div": "Left thorax \n heart structure"
  },
  "subject": {
    "reference": "http://mci.twhosted.com/BD1001",
    "display": "Shahrukh Khan"
  },
  "encounter": {
    "reference": "#E1001"
  },
  "asserter": {
    "reference": "http://providers.twhosted.com/D101",
    "display": "Dr. Heuvel"
  },
  "dateAsserted": "2011-10-05",
  "code": {
    "coding": [
      {
        "system": "http://bdshr-tr.twhosted.com/ICD10/I39",
        "code": "I39",
        "display": "Heart valve disorder"
      }
    ]
  },
  "category": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/vs/condition-category",
        "code": "Diagnosis",
        "display": "Diagnosis"
      }

    ]
  },
  "status": "confirmed",
  "severity": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/vs/condition-severity",
        "code": "6736007",
        "display": "Moderate"
      }
    ]
  },
  "onsetDate": "2011-08-05"
}

Where:

Condition.dateAsserted: Estimated or actual date the condition/problem/diagnosis was first detected/suspected.
Condition.category: A category assigned to the condition. E.g. complaint | symptom | finding | diagnosis.
Condition.status: The clinical status of the Condition or diagnosis. Possible values - provisional, working, confirmed, refuted.
Condition.certainty: Non mandatory. But used in many diagnosis conditions.We probably need to define a coded concept like SNOMED for certainty. TBD
Condition.severity: Value set defines
- 399166001: Fatal
- 24484000: Severe
- 6736007: Moderate
- 255604002: Mild
Condition.onset[x] - can be "onsetDate" or "onsetAge" : Estimated or actual date when the condition began.

NOTE: This definition of the "condition" is meant to be minimal set of definitions seen at a point of time, and maybe expanded if needed.

Complaint

Complaints are captured through FHIR condition, with "category" as "Complaint".

    "title": "Complaint",

    "id": "#C1002",

    "content": {

        "resourceType": "Condition",

        "identifier": [

                "value": "#C1002"

],

        "subject": {

            "reference": "http://mci.twhosted.com/BD1001"

},

        "encounter": {

            "reference": "#E1001",

            "display": "encounter"

},

        "asserter": {

            "reference": "http://providers.twhosted.com/D101"

},

        "dateAsserted": "2014-07-24T12:00:00+05:30",

        "code": {

            "coding": [

                    "system": "http://bdshr-tr.twhosted.com/ICD10/I39",

                    "code": "M79.605",

                    "display": "Pain in left leg"

},

        "category": {

            "coding": [

                    "system": "http://hl7.org/fhir/vs/condition-category",

                    "code": "Complaint",

                    "display": "Complaint"

},

        "status": "confirmed",

        "severity": {

            "coding": [

                    "system": "http://hl7.org/fhir/vs/condition-severity",

                    "code": "6736007",

                    "display": "Moderate"

},

        "onsetDateTime": "2014-07-03T12:00:00+05:30"

Where:

Condition.dateAsserted: Estimated or actual date the condition/problem/diagnosis was first detected/suspected.
Condition.category: A category assigned to the condition. E.g. complaint | symptom | finding | diagnosis.
Condition.status: The clinical status of the Condition or diagnosis. Possible values - provisional, working, confirmed, refuted.
Condition.certainty: Non mandatory. But used in many diagnosis conditions.We probably need to define a coded concept like SNOMED for certainty. TBD
Condition.severity: Value set defines
- 399166001: Fatal
- 24484000: Severe
- 6736007: Moderate
- 255604002: Mild
Condition.onset[x] - can be "onsetDate" or "onsetAge" : Estimated or actual date when the condition began.

API

save an encounter.

   POST /patients/{health Id}/encounters

get all encounters for a patient.

    GET /patients/{health Id}/encounters

get a specific encounter for a patient.

     GET /patients/{health Id}/encounters/{encounter id}

get all encounters for a catchment

     GET /catchments/{catchment code}/encounters

for details, please refer Catchment Encounters API

In this page:

Table of Contents

Versions Compared

Old Version 27

New Version 28

Key