Concept of Operations: Relating to the introduction of a Personally Controlled Electronic Health Record System
4.2 Information modelThe PCEHR System enables the collection of information from participating organisations, individuals and the Department of Human Services Medicare program within a series of conformant repositories. Information will be collected in the form of a clinical document.
For the purposes of the PCEHR System, a clinical document is an electronic document that contains personal health information about an individual. Examples include a Shared Health Summary, Event Summary, Discharge Summary, Pathology Result Report, Consumer Entered Health Summary, Medicare Information, etc.
Clinical documents will be extracted from source systems (see steps 1–2 in Figure 8) and loaded into one of the conformant repositories in the PCEHR System. While the specifics of the load process will vary, the intent is that clinical documents will be obtained by leveraging existing processes around discharge, referral, pathology, maintenance of practice-based health summaries, etc.
Figure 8: Example information flow
When a clinical document is loaded into a conformant repository, it will be validated against a common set of templates and the repository will inform the index that new information is available (see steps 3–4 in Figure 8).
When another user is ready to find clinical documents within an individual’s PCEHR, they will be able to use their local clinical system (or portal), to obtain authorisation to access an individual’s PCEHR, search the index and obtain a copy of the relevant documents from the pertinent repositories (see steps A–D in Figure 8). Once a clinical document has been reviewed, the local clinical system may give the healthcare provider the option of moderating information to store into their local electronic health record (see steps D-F in Figure 8)10.
The process described above is dependent on a minimum level of consistency between clinical documents. In order to ensure consistency, each clinical document will use a common set of ‘templates’, which describe the minimum data set for clinical documents and ensures consistency around information structure, clinical terminology and healthcare identifiers. In addition to common templates for clinical document, the PCEHR System will also be underpinned by common specifications and infrastructure for secure messaging and digital credentials.
This consistency ensures that when clinical documents are stored within conformant repositories (see steps 3–4 in Figure 8), they can be validated and safely indexed. Similarly, when a user needs to find a clinical document (see steps A–E in Figure 8), they can be found, retrieved and imported into local clinical systems (if required).
Top of page
Clinical Document Types and TemplatesInitially, the PCEHR System will support the collection of a range of clinical document types, including:
- Shared Health Summaries (see Section 4.3.1).
- Event Summaries (see Section 4.3.2).
- Discharge Summaries (see Section 4.3.3).
- Specialist Letters (see Section 4.3.4).
- Referrals (see Section 4.3.5).
- Prescribing and Dispensing information (see Section 4.3.6).
- Pathology Result Reports (see Section 4.3.7).
- Medicare information (including Medicare claims history, PBS data, Organ Donor and the Australian Childhood Immunisation Register) (see Section 4.3.8).
- Consumer Entered Health Summary (see Section 4.3.9).
- Consumer Notes (see Section 4.3.10).
The PCEHR System will support a range of additional clinical document types (see Section 2.8). Also note that while the PCEHR System supports a diverse set of clinical document types, the availability of the clinical documents from the conformant repositories will depend on the readiness of healthcare provider organisations to participate in the PCEHR Program.
All clinical document stored within the conformant repositories are based on a common set of ‘templates’, which specify the minimum set of data each clinical document is required to support.
In order to support indexing of clinical documents and to provide sufficient information about the subject of care and the clinical document’s provenance, the templates will ensure that all clinical documents contain the following base metadata:
- Document control information, including: unique document identifier, version number, unique identifier of any previous version, document type information (e.g. Discharge Summary, Event Summary, etc.), document template (see Section 6.5.1), and date/time the document was reviewed (or created) by the supplier.
- Details about the individual, including: name, IHI, date of birth and sex.
- The document source, including: name of the author, HPI-I, healthcare provider speciality / sub-speciality11 , organisation name, HPI-O, organisation address and communication details.
In order to support integration of source systems that are not yet ready to supply full structured / atomised data, the templates will be specified at three levels based on the amount of structure beyond the base set of metadata required. These levels are:
- Level 1 Clinical Document: The clinical document has the base metadata listed above, but the body of the clinical document is provided as text with the option of an attached PDF.
- Level 2 Clinical Document: The clinical document has the base metadata listed above and can provide all required fields described in the template in a structured form. Any coded data, such as a diagnosis or a medicine, that is not able to be provided using a community agreed terminology may be provided using text and optionally accompanied by coded data in a form the system is able to provide.
Any field marked as ‘required’ within a template must be filled in for the clinical document to be valid. If the author does not have information to put into a ‘required’ field, then they will be required to supply a reason why the field is not completed.
- Level 3 Clinical Document: Level 3 builds on level 2, with the exception that any coded data is supplied using a community agreed terminology relevant to the type of clinical document (e.g. Australian Medicines Terminology (AMT) and SNOMED CT-AU).
The design trade off accepted here is that in order to increase the breadth of content available in the PCEHR System, some views and reports may not be complete in the interim. In time, level 1 and potentially level 2 clinical document templates may be phased out as part of the change and adoption strategy and data quality strategy.
In order to ensure consistency of data structures between templates, the templates will use a common library of detailed clinical models (DCMs) to ensure consistency of information structures and clinical terminologies between different clinical document types [NEHT2010a]. This consistency is the basis for supporting a number of views and reports that extract data from different clinical documents.
10 Note that the PCEHR System permits download of single documents and does not permit a user to download an individual’s entire PCEHR as a single request. All access to the PCEHR System is also audited.
11 Information around specialties / sub-specialties to be provided in accordance with HI Service Provider classifications.
Top of page