Report on a preliminary analysis of the dataflow(s) in HealthConnect system

Transcription

1 Report on a preliminary analysis of the dataflow(s) in HealthConnect system Electronic Health Records: Achieving an Effective and Ethical Legal and Recordkeeping Framework Australian Research Council Discovery Grant, DP School of Law Deakin University, School of Information Management and Systems Faculty of Information Technology and Faculty of Law Monash University, Australia Hans Hofman Research Associate for Caulfield School of Information Technology Monash University February 2005 Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

2 Introduction The assignment was to follow the record throughout its journey in the HC system (where does it go and where does it reside). The record is interpreted as all information created and used in the different processes as envisaged and described in the different documents. The latest Business Architecture v1.9 document has an overview of the information objects (Ch. 9), which enables a clearer understanding what information is created and how it is related. Some things are as yet unclear. For example, the Clinical Information Project (now NEHTA) will define some entities (event summaries for instance; BA v1.9, p.39) which will probably be the same as the metadata schemas that are discussed under section 9.16 (BA v1.9, p.144). The documentation based on the process/procedural descriptions specify the creation of information but it is often difficult to ascertain where it goes. The data flows have been assessed using various different versions of the Business Architecture and System Architecture documents as they evolved during this Research Project. Different diagrammatic representations of the system are sometimes at too high level or are too limited in scope to help in the identification of data flows and stores. The different perspectives in the diagrams over time are not always helpful for understanding the interrelationships. This makes it difficult to follow where data/information/records is created and/or resides within the system(s). Processes and Information created by the Processes The following table attempts to identify major processes, the data or record generated, the data store assumed and the agents involved. Table 1 Processes and related information Processes Data / record Data store Agents involved C-79 1) data about Registration agent, Registration identification papers 2) unique assigned identifier 3) demografic data 4) written agreement with consent (details); 5) registration record 6) initial health profile 7) access control list 8) surrogates 1) in registration record (See also BA v1.9, p.21 where C- 74 is mentions registration databases) 2) index and registration record (?) +EHR 3) local provider system to be sent to HC HRS (on request) index + EHR 4) to be recorded in HC (part of EHR so in HRS) [+separate paper archive] 5) in outsourced registration agencies extracts to consumer index, synchronised to HRS nodes and registration agencies, EHR 6) to HRS for inclusion in EHR Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

3 C-80 Update consumer registration C-80 Update consent details/settings C-81 allow consumers to identify themselves and to change PIN/password Demographic data, Appointment of agents/ surrogates; Adding a National Health Identifier (NHI; when available); New/change consent data Authentication information (PIN + password) 7) Access Control List in outsourced registration agencies if established at registration, sent to HRS 8) consumer surrogate list (BA v1.9 C-79) index + EHR Access control list (?) (part of EHR) Reference database (C-79- b.1)? not further explained. Information contained in Index (BArc v1.9, p.143) + HC consumer registration services (or surrogate) (or surrogate) C-83 / C-84 Deregistration C-85 registration of consumer s death Signed application of consumer to deregister, Data about suspension of viewing access, Data about deregistration (flagging the appropriate entries as inactive), Notification of death Paper archive, Index (flagged entry) EHR (flagged inactive) Access control list (flagged inactive) HC registration services C-66 / C-67 Provider Registration C-72 Managing participation Provider registration details; Agreements with providers; Provider registration system (HC-level?) + Provider directory (HC level) (See C-71) Paper archive Registration agent Provider, Provider Organisation Provider Consultation C-75 to ensure the integrity of HealthConnect EHR information, consumer records and provider records and that adequate processes exist for identifying and 1) consultation record 2) event summary 3) record of accessing/ viewing HC 1) local system (CIS) 2) local system, and sent to assigned HRS to be added to EHR 3) local system (CIS + HRS); log and audit trail (?) Provider, Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

4 controlled handling of exceptions C-74 Monitoring access and auditing/reporting usage log and audit trail information from registration services, HRS/AEM services and the NDS; registration applications are to log all transactions in an audit trail, which is to be archived indefinitely. (BA v1.9 p.156) Log and audit trail (HRS + transmitted to NDS) Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

5 Derived information entities The second table regards the information entities that can be derived from the preceding analysis, their main elements and the responsible agent. Table 2: Information entities Data entities Information content Where Responsible Agent HC central HC governing body index EHR - Registration EHR - Access Control List EHR Event Summary Copy of EHR, for research and planning purposes, and for deidentified record analysis details (their HC identifier, their personal details, and a link to the HRS on which their EHR is held) + authentication information (PIN and password) All in secure form. Identification information, registration details Provider organisations + consumer confirmation + preferences Event summaries of different types Basis for EHR views (subset of EHR), notifications (triggering predefined actions), lists (subset for a target audience) Event summaries of different types In a format complying with standard HC metadata needs to be defined further May be copied to HRS (part of EHR) HRS (as part of EHR), and registration system (= provider system/cis)? HRS (as part of EHR) EHR for each consumer on one specific HRS National Data Store or through approved provider Provider identified as the Approved EHR Manager (AEM) HC governing body? Reference BA v1.9 (p.26, point i); BA v1.9 (p.116 section 8.9) BA v1.9, p C-74 registration databases, BA v1.9-attach, p.21; and BA v1.9, p.115, where they speak of setting up the consumer with a record on an HRS/AEM ; about consumer details: BA v1.9, p BA v1.9 (p.25, point e) Section 9.6 of BArc v1.9, p (BA, v1.9, p.7) and (BA, v1.9, p.41) BA, v1.9. p. 129 (says EHR extracts referring to CEN EN notion of extract) Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

6 Surrogate List Provider Directory Authentication information Record of the identification of authorised staff Log and audit trail information Metadata schemas Reports Operational policies and standards for consumer registration Information on Alias or agents Provider details Login details (PIN and password) Unique sequence nr., date and time transaction/access, unique identifier for agent from where access was performed; for EHR inputs: identification type of information, complete event summary transaction; event summary status indicator per summary; for EHR output (including notifications): identification type of information, complete output transaction. All changes to EHR must be versioned. EHR in its totality (different document types), including retention of no longer valid schemas Aggregated information derived from EHR Regards consumer registration? Part of Index (is not mentioned there)? HC central: HealthConnect will need to maintain its own information on providers, to track their HealthConnect status and to efficiently manage their HealthConnect access privileges. In the future National Register; Part of Index Locally In HRS (?) and NDS Metadata repository? HC governing body? BA, v1.9. p.131 BA v1.9 (p.26, point j) BA v1.9 (p.25, point e2) BA v1.9, p.118 (section 8.11) HC central BA v1.9, p.143 Provider organisation HC central (BA v1.9, p.118 section 8.11) BArc v1.9, p BA v1.9, p (section 9.16) HC central BA v1.9, p.142? HC central BA v1.9, p31 (C-87) Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

7 Issues arising from the analysis: EHR The EHR is intended to complement the provider s records by facilitating the sharing of summary healthcare information in the form of standardised event summaries and composite views of information in event summaries, between providers that are involved in the care of a consumer. (BA, v1.9, p.39) The EHR will contain clinical information that is of relevance to other providers. It is proposed that the EHR will be comprised of a series of event summaries, each of which will contain summary information relating to the services provided at a given healthcare event. (BA, v1.9, p.39) The Clinical Information Project, a major project contributing to HealthConnect, is developing the initial set of event summaries and views in consultation with consumer and provider representatives. (BA, v1.9, p.39) An EHR seems to be an amalgama of different information entities: Based on Chapter 9 of BA v1.9, it contains: identifier; data key demographic data about the consumer, including date of birth, sex, contact details, next of kin etc; Access Control List, which identifies the providers which the consumer has allowed to access the EHR associated with this is the option for authorised providers to request notification when specific types of event summary arrive for processing into the EHR; A long-term collection of all Event Summaries incorporated into the EHR, each containing information received from points of care (eg. a GP surgery or hospital), typically providing salient information about one or more care event; EHR Views commonly referenced, clinically meaningful aggregations of EHR information drawn from one or more event summaries (eg. the critical view which shows problems, alerts and medications, care plan summary, or a microbiology sensitivity report); EHR Lists commonly referenced sets of similar clinically meaningful data items selected from the EHR, e.g. active problems, current medications, therapeutic precautions, cumulative laboratory report ; and EHR Version Log, Access Log and Audit Trail, which are logically part of each consumer EHR but may be implemented as part of a different physical database to the EHR itself. According to the Health Document Metadata Model (SA v1-72, July 2003, p.17) a schema will be developed for some of these entities. Event summaries (different types; + EHR lists). An event summary is a subset of information about healthcare events that are relevant to the ongoing care of a consumer. (BA v1.9, p.33). HealthConnect will not proactively extract data from operational systems, but will receive event summaries sent by the operational systems at the discretion of the consumer and system user. (BA, v1.9, p.43) EHR reports will contain aggregated data ( formatted view ). Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

8 Views can be structured. The documentation references the primary view and the Health profile view [ Users of HealthConnect will access data using pre-defined views suited to the specific needs of consumers and providers. The priority views identified to date are the primary (or critical ) view; and the health profile view. (BA v1.9, p.17)] Information, once submitted to HealthConnect, may not be deleted or altered; however corrections or amended information may be included in the EHR by issuing revised versions of the information which will be used in place of the earlier versions with appropriate annotations. ((BA v1.9, p.33) Storage: Local system Event summaries (those sent arising from health care event; those received for incorporation into the local system) The actual medical records Consent? (including paper archive, also implicit consent to send individual event summaries from local system to HRS) Registration information? Signed applications for deregistration paper archive but not clear where. (?) HRS Each HRS will hold and manage the shared electronic health records (EHR) for many consumers. (BA v1.9, p.7). each consumer s EHR being stored in a single HRS. (BA, v1.9, p.41) a limited number of HRS implemented across Australia each of which may be operated by public or possibly private organisations referred to as Approved EHR Managers (AEMs). (BA,v1.9,p42) The technical architecture identifies the requirement for a peer-to-peer network of HealthConnect Records Systems (HRS), with each HRS providing EHR storage and access services for a defined group of users (Refer to, Section 4.1). (SA1-72, p.18) NDS A copy of the EHR material will to be transmitted to the National Data Store (NDS) for archiving and long-term retention. This National Data Store will be used to support all secondary use of HealthConnect EHR data for research and planning purposes, while all operational interaction with a consumer s EHR will occur through the HRS. Access to the NDS will be tightly controlled. (BA, v1.9, p.7). the National Data Store be used to support all secondary use of HealthConnect EHR data for research and planning purposes, (BA, v1.9, p.41); for de-identified record analysis. HC (national HRSA + Directory) Registration system including Index Access System Provider Access System National Health Provider Directory (eventually) (Information about) Policies, rules, standards National Health Identifier Service (s) National Health Metadata Repository National Data Store Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

9 Note: there is some confusion what the national level encompasses when reading the different documents: 1) in SA01-60 (July 2003) Systems Architecture Overview v0.9, on p.39 in the HC Conceptual Systems Architecture it is suggested that at the National Coordination Layer there will be HC directory and data services (data store). The HC directory includes a national register of users (= Index). Also indicating that the directory in practice may be chached on each HRS (will entail synchronisation issue). It is assumed that the data services will include the NDS. 2) in SA1-72 (July 2003) Systems Architecture v.0.9, in the HC Application Architecture on p.42: shows the consumer directory at national HC coordination level as well as persistent data services, which may include the NDS. 3) in BA v1.9 (p. 6 and 154, figure 11.1) there is the subtle distinction between the National Health layer and the HC layer. It shows for example in the National Health Provider Directory and the HC Provider Directory. The NH layer does not yet exist. That may be the reason it is not shown yet in application architecture. It may very well get a separate architecture, which will entail interfacing issues. On p. 148 (figure 10.1 under L) it is suggested that the HC infrastructure consists of Metadata Repository, National Data Store, Audit Trails, Index, Provider Directory and Networks & Systems; And p.148, under M: NH Identifier Service, NH Provider Directory, Health Information Standards, Terminologies & Data Sets, NH EHR models. Preliminary conclusions it seems to be the intention to have at national level two distinct entities : the National Health Infostructure and HealthConnect, where HC represents the actual implementation and NH infostructure the supporting /governing (?) layer, but elsewhere in the documentation it is stated that the NH Infostructure sits outside HC. It is difficult form all the figures/diagrams to derive where the information actually will reside (what systems/computers and where). It is rather a conceptual picture. It may very well be distributed such as the HRS will be. So physically locating the information may be an issue. The naming in the different perspectives (in the different documents) taken is rather confusing and makes it difficult to compare. In BA v.1.9-attach, p under C-71 there is a list of systems/ infrastructure components: (a) HealthConnect Records System (HRS) (for use in initial HealthConnect implementations, where agreed with participating jurisdictions); (b) HealthConnect Registration System (including Index); (c) HealthConnect Provider Registration System (including Provider Directory); (d) HealthConnect Message Handling and Transport components; (e) HealthConnect Access Portal; (f) HealthConnect Provider Access Portal; (g) CIS/CHIS Interfaces; and (h) Access to appropriate ehealth transmission services and ehealth message bank services. Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

10 They can be identified mostly in figure 11.1 on p. 154 (BA, v1.9) as well, with the exception of the National HealthConnect applications (such as NDS maintenance and reporting, HC metadata maintenance and HC Administrative applications) which are not mentioned in the BA v1.9-attach document (under C-71). The administrative applications are not covered in the documentation provided. In this diagram there is also a connection to storage, but it is not very clear whether this storage is part of the application or a separate system. Synchronisation Several sets of information reside in different places at the same time. This is particularly relevant to the EHR, consumer information and provider information. Provider s will maintain their own clinical records /systems. HC will have an extract (event summaries of different types). HealthConnect will not replace providers own clinical records or clinical information systems. Providers will continue to maintain their own consumer health records but may choose to incorporate selected HealthConnect EHR information in their records or clinical information systems. (BA v1.9, p.29). Also synchronisation issue between EHR in operational systems (=HRS) and EHR-copy on NDS. Each HRS is to regularly forward copies of EHR information and logs of audit trail accesses, to the HealthConnect National Data Store for archival storage and approved secondary uses (BA v1.9, p.155) registration information A copy of parts of the consumer s information, necessary for ensuring accurate identification of the consumer eg name, is held on the consumer index for use in managing HealthConnect but should not be made available to external applications using the index. (BA, v1.9, p.156) as well as in the consumer registration system/application (?), which seems to be the interface, and in the EHR. See also BA v1.9, p.140: Because some (but not all) consumer details will be accessible via the EHR and, also, held in the consumer index, the maintenance of consumer details will need to be carefully synchronised between HRS nodes and the registration system. This will include: (a) The registration application both loading initial consumer details to the restricted zone of the consumer index and passing them to the HRS when the consumer first registers with HealthConnect; (b) The registration application providing updated consumer details to both the consumer index and to the HRS when the consumer updates their details through a HealthConnect consumer registration agency; and (c) A means for consumer details in the registration application and the EHR to be updated simultaneously, when changes are made online by the consumer (or an authorised provider with access to the EHR). Also, BA v1.9-attach, p.28: Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb

11 (f) Modifying the consumer s entries on the HealthConnect consumer index and notifying the appropriate HRS of the change. In SA01-60 (July 2003) Systems Architecture Overview v0.9, on p.39 in the HC Conceptual Systems Architecture it is suggested that HC directory includes a national register of users (= Index) and that the directory in practice may be cached on each HRS (will entail synchronisation issue). This feature is not mentioned again in later documents. Provider registration information Selected parts of the provider s information may subsequently be maintained by the provider via online interaction with HealthConnect itself or the HealthConnect provider registration agency. BA, v1.9, p.156) Amendment, corrections and withdrawal of information In all cases the original information will be kept for medico-legal and audit purposes, but will no longer be disclosed by HealthConnect. (BA,v1.9, p.55). No indication where it will be kept (e.g. in NDS or still on HRS or elsewhere). Access HealthConnect will only send the information as a result of a request for the information. The composition of the information in some views will be targeted to a specific type of user. (BA,v1.9, p.44) Users can view them [event summaries] through a set of pre-defined views (BA v1.9, p33). The use of predefined EHR views (some of which are expected to include search parameters) will ensure that the results of requests represent clinically valid data and that the processing workload which would be required to service queries do not adversely impact performance of the overall HealthConnect system. (BA, v1.9, p.45) Hans Hofman: Report on an Analysis of the Dataflows in HealthConnect System, Feb