PCEHR-Implementation

PCEHR Implementation As I ask NEHTA time and time again- which one are they using? It seems that a hodge-podge of bits of standards are being used and we'll end up with a silo of Australian e-health records that are useless OS. Juanita

I believe we now have 12 projects, and therefore I assume we will have 12 different PCEHR implementations. NEHTA says lots of "do" and constantly backs away from the "how". This is why we have different HL7 implementations in the first place as there is not enough of the "how". Why can't we learn from the past?.

Its unclear to me who has written the above but I surmise it is David More. (Not me DM) Can people pls sign their contributions.(I did) The "How" question is so easy to answer in brief way as it has many facets. Here are some of the topics that might be considered> What System Design methodology will be used? What system implementation strategy and therefore tools will be used? How will maintenance of the software be managed that is who will do the maintenance, who will be able to lodge change requests, what mechanism will be created to enable and manage change proceess. Ther are two models that could be use: 1. a closed proprietary model where changes requests are kept secret, 2. an open source model, where the change process is managed as a public information board that everyone can see. There are more issues I will come back to them later jon patrick

(Terry Hannan) Jon, my first hand experince is with an Open Source model ([|www.OpenMRS.org]) and evidence would suggest that this model has many positive advantages over proprietry software. This application is an internationa;;y frre downlaodable aplication thta continues to be adaptable to individual local encironments and the data for each clinical environment is managed at that site but is 'stnadarised' in the worls wide applications. See Concept Dictionary paper by B. Mamlin and P. Biondich [AMIA symposium 2007 and other more recent publications from this collaborators group]. There are several collaborators YouTube videos on the OpenMRS concept dictionary.

The benefits of leveraging an open source model as Terry has described above certainly sounds like a logical move. I have not yet had the opportunity to have a good look at this, however if my only thought / reservation is whether it will meet the requirement of the Australian health system. I supect that it probably will, however would need to have more of a play with this system first so that I can convince myself of this fact. Andrew C

I would definitely favour an open source licensing and project management approach to the PCEHR. This could be done by the Commonwealth funding a range of corporations to make contributions to different aspects of the system. Subsequently they could then fund a group to sustain the Open Source effort. Then interested users could make additions in areas where they have most interest. Also the PCEHR will notlfy if it seen to be controlled by a particular corporate entity whose behaviour you would expect to be self-serving.

Furthermore I would favour an architecture that was more orientated on the indexing of data in its locations than the uploading of data into a central repository. The indexing strategy can be brought on line more quickly, has lower overheads at the central storage location, has lower engineering and design demands, can be more easily brought to a demonstration state, and can be expanded more readily. This is not to argue that no data should be centrally located, for example, life critical information might be stored centrally in case the real storage location is down. Jon Patrick

DM - Just remember the Government is steeped in secrecy (look at the NDA you need to sign to get access to the IHI interface code). Open source is not in their 'control-freak' interests in my view!

I note no one has really considered how short we as a country are of all sorts of e-Health implementation skills and all the other things you need. This will be ratelimiting I believe.

JP -David, your point is valid but I'm sure you of all us would advocate to say what you think is needed and then compromise only when you absolutely have to. Your comments about a shortage of skills only reinforces my argument. We need to recruit people into the EHR development space as there is a create shortage of interested talent. An Open Source project has a real chance of doing that especially if it is sponsored by the Government.

Paul Clarke. In reference to JP's and DM's points above and as a strating point, the implementation approach needs to be underpinned by at least the following (this is very much a skeletal view only): a. A multi-layered governance model - this is a highly complex project which requires a well defined governance structure that embodies a high level of transparency and accountability and which allows enaggement of teh critically necessary stakeholder communities. Whereas this should ultimately conform to a conventional pyramidal structure, with clear lines of authority and reporting, there is also a need to specifically address design, implementation, operational governance and quality assurance / evaluation requirements within this overall structure, which will enable specific management issues to be optimally addressed. These specific governance arms would be accountable to the strategic and overall project management at the top of the pyramid. For example, the PCEHR Design governance arm of the structure would need to preside over all technical apsects of the design process - including design methodology, technical architecures, etc, whereas the PCEHR Implementation governance would include responsibility for the implementation planning, implementation methodology, project management and delivery, systems procurement, systems integration etc. Within these governance arms would be technical / advisory groups and management groups with clear roles and responsibilities, lines of authority / reporting and collaboration both within and between governance groups. Management of change requests and risk management would need to be optimally addressed within the appropriate governance arm in the first instance with a clear escalation process to ensure change requests and risks are appropriately assessed and addressed efficiently and at the appropriate level. Similarly, a dispute resolution process needs to be fully articulated to ensure clarity of how disputes are resolved within the governance structure. b. Implementation methodology dealing with the full specification of deliverables, deliverable entry and exit acceptance criteria, testing - unit, systems, integration and user acceptance testing (including functional, process / workflow, systems performance, parallel and load testing), implementation standards, systems conversion / production handover, c. Project management, including detailed planning - development of a detailed project planning documentation covering the overall project, separate project stages and all sub-projects, resourcing, scheduling / timefarmes, budget management, project management deliverables, project standards - covering systems / software environment management, systems security, access, data backup, retrieval, archival etc), project reporting, risk management, project staging and management of many sub-projects, vendor contract management etc d. Quality management - planning, resoucing, preparation, review and acceptance of deliverables etc e. Communication and change management - including planning, communication of project status, information management, consultation, training / education etc f. Process / Workflow planning, consultation and redesign, and implementation g. Systems Integration -detailed planning, technical design (in conjunction with the Design governance group), standards compliance, testing and implementation h. Systems Procurement - specification, tendering, evaluation, contract negotiation and selection of system vendors etc (note - this would at least address the issue regarding the development of clinical feeder systems and systems interfaces required between provider systems and the PCEHR systems) i. Production and Support - in conjunction with the Operational Governance arm - planning, resourcing, post 'go-live' support and maintenance, issue management / escalation etc

Software maintenance is an issue that would need to be dealt with at a number of levels - policy / strategic level (which would address issues such as those raised by JP), at a project management level (involving systems procurement) and at the operational level (where ultimately all ogoing mainenance contracts with PCEHR systems or outsourcing vendors would need to be managed)

I'm really concerned about standards information and the fact that these will not be made public given the PCEHR "underground" and anecdotal comments about the lack thereof in this sphere. Klaus gave us the most feedback on standards last week when he spoke about the HL7 meeting in Sydney. I asked NEHTA about whether standards would be made publicly available and they replied "No, however at a later stage, the Standards Matrix will form the basis of the PCEHR Standards Catalogue. " Too much non-information devils this project but NEHTA are determined to make the July 2012 deadline.

Also, people seem to overlook the fact that unless the clinician is registered for the PCEHR, then the patient's own PCEHR is useless. Juanita Re my first comment on this page about silo Australia, this was borne out by a comment Mukesh made last week about a "card"that people may carry in order to access the PCEHR outside Australia, maybe for emergencies too? Juanita

Back to PCEHR Overview Page