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

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

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 where 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"/>
   </subject>identifier>
   <encounter>
     <reference <date value="urn:07f025242015-7647-43c1-a579-0c2c80f285ed01-07T12:00:15+05:30"/>
   <status  <display value="Encounterfinal"/>
   </encounter><subject>
   <section>
  <reference value="http://mci.twhosted.com/api/v1/patients/5893922485019082753"/>
     <display  <content>value="Monika Ramesh"/>
   </subject>
   <encounter>
     <reference value="urn:40b43d8a07f02524-b5827647-408043c1-8c04a579-93697b82a7950c2c80f285ed"/>
        <display value="TemperatureEncounter"/>
     </content>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.

<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 clinic
• 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". 

Observation

Observations are made for measurements and simple assertions made about a patient. Lets say, the patient's temperature reading was recorded as 101 F.

<Observation xmlns="http://hl7.org/fhir">
   <identifier>
      <value value="urn:40b43d8a-b582-4080-8c04-93697b82a795"/>
   </identifier>
   <name>
      <coding>
        <system value="http://tr.twhosted.com/openmrs/ws/rest/v1/tr/concepts/a1257651-7473-4c9b-bb0a-1244c5f3c09d"/>
        <code value="a1257651-7473-4c9b-bb0a-1244c5f3c09d"/>
        <display value="Temperature"/>
      </coding>
   </name>
   <valueDecimal value="101.0"/>
   <status value="final"/>
   <reliability value="ok"/>
   <subject>
      <reference value="http://mci.twhosted.com/api/v1/patients/5893922485019082753"/>
      <display value="Monika Ramesh"/>
   </subject>
</Observation>

Where:

• identifier - is the unique id of this resource within the document. 
• name - describes what happened. This is a CodeableConcept. In the above example, it explains that "Temperature" was recorded. The system and the coding further uniquely identifies the concept in the Terminology Registry. 
• value[x] - result of the observation. It maybe - valueQuantity, valueString, valueDecimal, valueRation etc etc.
• status - status of the observation. example - final, registered etc
• subject - reference to the patient. 

Again note, how the identifier of the above observation is used to link with the composition section.

Diagnosis

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

<Condition xmlns="http://hl7.org/fhir">
   <identifier>
     <value value="urn:e45dbdca-4e39-4a79-b1b8-fd622fdff6e3"/>
   </identifier>
   <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>
   <asserter>
     <reference value="http://pr.twhosted.com/providers/18.json"/>
     <display value="Dr. Azad"/>
   </asserter>
   <dateAsserted value="2015-01-07T12:00:15+05:30"/>
   <category>
     <coding>
       <system value="http://hl7.org/fhir/condition-category"/>
       <code value="diagnosis"/>
      <display value="Diagnosis"/>
     </coding>
   </category>
   <code>
     <coding>
      <system value="http://tr.twhosted.com/openmrs/ws/rest/v1/tr/referenceterms/2218636a-0ef0-4fb1-ac7e-cf2a915b0ee4"/>
      <code value="J11.1"/>
      <display value="Influenza due to unidentified influenza virus with other respiratory manifestations"/>
     </coding>
   </code>
   <status value="provisional"/>
 </Condition>

Where:

• Condition.identifier - is the unique id of this resource within the document. Note, how the identifier is linked to the composition through the section identifier.
• Condition.subject - the reference to the patient resource
• Condition.encounter - reference to the encounter where the diagnosis was made. Note how it points to the encounter identifier in the same document. 
• Condition.asserter - the provider who asserted this condition
• Condition.dateAsserted: Estimated or actual date the condition/problem/diagnosis was first detected/suspected.
• Condition.code - identifies the condition, problem or diagnosis. In this case, the system is the URL reference where the code J11.1 can be found.
• 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.

API

save an encounter.

   POST /patients/{health Id}/encounters

get all encounters for a patient.

    GET /patients/{health Id}/encounters

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

get all encounters for a catchment

     GET /catchments/{catchment code}/encounters

     </coding>
   </code>
   <status value="provisional"/>
 </Condition>

Where:

• Condition.identifier - is the unique id of this resource within the document. Note, how the identifier is linked to the composition through the section identifier.
• Condition.subject - the reference to the patient resource
• Condition.encounter - reference to the encounter where the diagnosis was made. Note how it points to the encounter identifier in the same document. 
• Condition.asserter - the provider who asserted this condition
• Condition.dateAsserted: Estimated or actual date the condition/problem/diagnosis was first detected/suspected.
• Condition.code - identifies the condition, problem or diagnosis. In this case, the system is the URL reference where the code J11.1 can be found.
• 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.