Context
Shared Health Record (SHR) serves as a repository containing person-centric records 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 each patient, an Encounter is stored in SHR. The 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 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 patient.
The EMR sytsem at the Facility would communicate with SHR by means of a “document”, formed to provide coherent context for an “Encounter” information. The context description of an encounter can be modelled using FHIR resource “Composition”.
Basic Structure
A Composition resource “Document” will have
- Header, having number of sections within that point to.
* Section for chief complaints (referencing “Condition”)
* Section for observations made by the doctor like clinical assessment in forms of text
* Section for physical examination (Blood Pressure)
* Section for medication
* Section for tests
* Section for encounter
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.
Such a document is composed by "bundling" FHIR resources together. This bundle will include contents described above. The representation will have a "bundle" resourceType. See here for the mandatory attributes.
{
"resourceType" : "Bundle",
"title" : "Encounter",
"updated" : "2012-09-20T12:04:45.6787909+00:00",
"id" : "urn:uuid:50ea3e5e-b6a7-4f55-956c-caef491bbc08",
"category" : [{
"term" : "[Tag Term]",
"label" : "[Tag Label]",
"scheme" : "[Tag Scheme]"
}],
"totalResults" : 3,
"entry" : [
{
"title" : "Encounter between patient X and Doctor Y",
"id" : "urn:uuid:abcDa3e5e-b6a7-4f55-956c-caef491aYh1x"
"content" : {
"resourceType" : "Composition",
...other elements...
}
},
... other entries ....
],
"signature" : "<signature xmlns=\"http://www.w3.org/2000/09/xmldsig\">...</signature>"
}
Composition
For detailed information of definition of composition (attributes), see here
{ "resourceType": "Composition", "identifier" : { "value" : "Encounter-1234" }, "date": "2012-01-04T09:10:14Z", "type" : { .. }, "status": "final",
"confidentiality": { .. },
“subject”: { <ref to patient> }, “author” : [{ .. }], “section” : [ { .. } ] }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" : {}
}
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
NOTE: there are many other attributes of FHIR encounter (like hospitalization, location etc). They maybe included as we see use cases.
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}/encountersget all encounters for a patient.
GET /patients/{health Id}/encountersget 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...