Showing posts with label #healthcare. Show all posts
Showing posts with label #healthcare. Show all posts

2016-07-01

Electronic Health Records ( #EHR ) implementation with #blockchain, #BPM, #ECM and #platform

This blogpost is an updated version of the chapter 3 from “Technology enabled healthcare transformation” ( see http://improving-bpm-systems.blogspot.ch/2014/07/technology-enabled-healthcare.html ).

The main concept is that a person (or his/her legal representative) is the only the owner of his/her personal EHR. Other participants in the healthcare may use some of the person’s records only within some explicitly-defined contexts.

The following technologies are employed:
Special thanks to Charles Webster MD @wareFLO https://twitter.com/wareflo for a review of this article.

1 General definition from www.healthit.gov



www.healthit.gov defines person’s Electronic Health Records (EHR) as, at their simplest, digital (computerized) versions of patient's paper charts. In other words, a person’s EHR is a set of all the health-related records of a particular person which are available in some digital formats. But a person’s EHR, when fully up and running, are so much more than that.

A person’s EHR is real-time, patient-centred records. They make information available instantly, at any time, in any place and from any device. And they bring together in one place everything about a patient's health. A person’s EHR can:
  • Contain information about a patient's medical history, diagnoses, medications, immunization dates, allergies, radiology images, and lab and test results.
  • Offer access to evidence-based tools that providers can use in making decisions about a patient's care.
  • Automate and streamline providers' workflow.
  • Increase organization and accuracy of patient information.
  • One of the key features of a person’s EHR is that it can be created, managed, and consulted by authorized providers and staff across more than one healthcare organization. A person’s EHR can bring together information from current and past doctors, emergency facilities, school and workplace clinics, pharmacies, laboratories, and medical imaging facilities.

2  EHR as a component of the healthcare platform


The EHR component is a tool which operated many person’s EHR.

Certainly, the EHR component is the core of component of the healthcare Common Unified Business Execution (CUBE) platform and an implementation of the EHR component is a must. Within the healthcare CUBE platform, the EHR component can be architected in accordance with this conceptual view.

3 A bit of cryptography

  • Hashing is a cryptographic procedure to map a digital object of arbitrary size to data of fixed size (called “hash”). Features: easy to compute, irreversible (not feasible to generate original digital object from its hash), commitment (any change in the digital object changes its hash) and collision free (not feasible to find two digital objects with the same hash). 
  • Public and private keys are a pair of keys of asymmetric cryptographic algorithm. A digital can be encrypted by one of those keys and decrypted by the other one.
  • A digital signature is a hash of a digital asset (e.g. a message, document, data) encrypted with the owner’s private key. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, that the sender cannot deny having sent the message (authentication and non-repudiation), and that the message was not altered in transit (integrity).

4 Records keeping

A person’s EHR are kept in a private storage which is accessible only by the owner (i.e. this person). Records are encrypted by person’s public key (thus only the owner can decrypt them with his/her private key). If the private key is compromised then the records must be re-encrypted with another private key.

The digital signature of a record is kept in a public storage which is based on the blockchain; thus, thanks to blockchain, no one (even the owner) can change this digital signature and thus everyone can check that the record has not been changed even by its owner.



Traditionally, personal healthcare records embed the name of a person (denominated record) thus creates a problem between the person’s privacy and the use of his/her EHR for medical research activities. A solution of this problem is to have anonymised version (anonymised record) of traditional personal healthcare records.
From the point of view of the enterprise content management, a denominated record is a composite (or compound) record which comprises anonymised record (some medical information) and some personal information. Some medical organisations already practice anonymisation of some records by replacing a patient’s name by some identifier. For example, a blood sample container has a barcode (or RFID) which is also attached to patient’s information page. Also, an identifier is used to hide a patient’s name in communication with external service providers such medical tests labs.

5 Records exchange


A typical practice of electronic document distribution is to add an annotation (e.g. as a watermark or running header or footer) to whom a particular copy of the electronic document has been sent. Finally, this personalised record is electronically signed by the distributor.


6 Context for records exchange


Ideally, all the records must be originated as anonymised version and be explicitly associated with the name of a patient when necessary (so called late-binding approach).

A person (or his/her legal representative) is the only the owner of his/her personal EHR. Other participants in the healthcare may use some of the person’s records only within some explicitly-defined contexts. Other participants in the healthcare must explicitly request some person’s records (e.g. lab tests, etc.) from the owner (i.e. the patient). Such a request must be executed only in the context of a well-defined process/workflow/case in which the patient and the requestor are involved (see 2.5.3 in the original article).

The exchange uses the concept of “deposit box” which is a short-life-time (temporary) private storage for the each act of exchange. A deposit box is accessible by the record’s owner and, then, the record’s recipient. Imagine that some paper documents were copied and put in an envelope. Some deposit boxes may be protected by a one-time password. Such a deposit box can be part of a particular process case.

7 Use case 1 – from a patient to a medical office (i.e. a doctor)


Below is an example of how the exchange between a patient and a medical office should be carried out (keep in mind 2.5.6 in the original article). The situation: the patient made an appointment to visit a doctor. The catalogue of the patient’s records (title, date and some other metadata only) is made available for the doctor. The doctor has indicated which patient’s records are necessary for this visit. The patient has to send some of his/her records before the visit. After the visit, the doctor sends to the patient some new records. See a process fragment below.

Records exchange is carried out in the following way (see the red markers in the illustration below):

1) As part of the “visit doctor” process, the patient got a task to send a list of his/her records to the doctor.

2) Anonymised versions (ideally) of requested records are annotated (by indicated to whom this copy is to be sent) and they are additionally protected by:
  • a. the doctor’s public key for this patient;
  • b. maybe, the process case private key which has a short life-time and, 
  • c. maybe, an one-time password.

3) The protected records are uploaded to a deposit box.

4) Hashes of all those records are sent in a public storage.

5) A link to this deposit box is communicated to the doctor (actually, to his/her) medical office.

6) The records from the deposit box are fetched, decrypted and validated (via hashes which are stored in the public storage) by a medial office employee to store them into a private storage of this medical office.

7) The deposit box is “destroyed”.



8 Use case 2 – from a medical office (i.e. a doctor) to a patient


The flow of data is indicated by blue markers in the illustration below.




9 Private storage, public storage and deposit box implementation


A private storage is a cloud-based protected and encrypted storage. For example, https://www.securesafe.com/en/

A public storage is a public blockchain. It is used to validate the integrity of records because a hash for each record is stored in the public storage. Metadata are very important.

A deposit box is a protected short-life storage which can change the owner only one time – think about an envelope. Each particular process case may have several deposit boxes. Each of them may be passed from one process participant to another.

Secure exchange may be built on the Open Whisper technologies - https://whispersystems.org/ 

10 From your current EHR to the common ideal EHR


It will be in one of next blogposts.


Thanks,
AS

2015-12-31

Typology of platforms

Platform concept

platform, noun
pre-existing piece of software to provide comprehensive functionality to other software pieces (i.e. applications) during some phases of their lifecycle


Note: Good platforms make simple things simple and complex things possible.
Note: "Piece" is a unit of deployment.
Note: All platforms are digital.
Note: Types of platforms mentioned below may be mixed in a particular software product.

Well-designed platforms follow the enterprise pattern Platform-Enabled Agile Solutions (PEAS) - see http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html

See also "Achieving synergy between diversity and uniformity via platforms" http://improving-bpm-systems.blogspot.ch/2016/01/achieving-synergy-between-diversity-and.html and "Platform-based #digital transformation (example egov)" http://improving-bpm-systems.blogspot.ch/2016/01/platform-based-digital-transformation.html

Development platforms 

Origin: IDE
Typical characteristics: developed applications operate outside the platform
Typical provisioning: on-premises
Typical creator: FOSS or COTS

Technological platforms

Origin: runtime libraries
Typical characteristics: technology encapsulation for applications
Typical provisioning: on-premises
Typical creator: FOSS or COTS
Examples: ESB products, mobility, API gateways, etc.

Operational platforms

Origin: OS
Typical characteristics: platforms improve non-functional characteristics of applications
Typical provisioning: on-premises
Typical creator: FOSS or COTS or home-made
Examples: automation toolset for devops, monitoring, performance measurements, containers, virtualisation, application servers


Application platforms (programmable monoliths)

Origin: IDE
Typical characteristics: applications operates within such platforms only (beware of the vendor lock-in)
Typical provisioning: SaaS or PaaS, APaaS or on-premises
Typical creator: FOSS or COTS
Examples: BPM-suites, etc.

Functional platforms (configurable monoliths)

Origin: corporate functions automation
Typical characteristics: generic solutions have to be configured for needs of a particular business
Typical provisioning: SaaS or PaaS or on-premises or hybrid
Typical creator: FOSS or COTS
Examples: ERP, CRM, ECM
Note: Also called "Vendor platforms"


Intermediation platforms

Origin: portals
Typical characteristics: middleman between service consumers and service providers
Typical provisioning: IaaS or on-premises
Typical creator: home-made
Examples: Uber, Airbnb, Facebook, Alibaba, Paypal
Note: The owner of an intermediation platform helps to match demand and supply without any ownership over supplied resources (Uber does not owe cars, Airbnb does not owe hotels, Facebook does not generate any content, Alibaba does not produce consumer goods).
Note: Also called "Digital platform" or marketplace.

Business execution platforms

Origin: corporate functions automation
Typical characteristics: a coherent set of functionality sufficient to run business in a particular business domain as a set of solutions which are assembled from microservices.
Typical provisioning: hybrid or on-premises
Typical creator: FOSS or COTS
Examples: Salesforce
Note: Business execution platforms may be collected from previously mentioned platforms.

Corporate Unified Business Execution (CUBE) platforms

Origin: digital transformation, application portfolio rationalisation, application portfolio modernisation,  legacy ERP transformation, etc.
Typical characteristics: whole-enterprise-specific business execution platform
Typical provisioning: hybrid
Typical creator: home-made
Example: http://improving-bpm-systems.blogspot.ch/2015/10/enterprise-patterns-peas-example-cube.html
Note: Corporate unified business execution platforms are collected from previously mentioned platforms.
Note: Also called "Digital business platforms".


Potential industry-sector synergy


Any corporate within the same industry-sector do, in principal, the same things but in slightly different way. If a corporate unified business execution platform enables synergy between diversity and uniformity then the same platform may serve the whole industry-sector (public services, healthcare, smart-city, etc.).




Examples:
Thanks,
AS

2015-07-25

#BPM helps the medical emergency service to save lives faster

With the use of BPM, the medical emergency service in Geneva reduced the service time (from a call to an emergency team on place) in 2 times!
Their BPM is at level "Explicit" - see slide 7 in http://improving-bpm-systems.blogspot.ch/2015/06/help-sme-becoming-digital.html

Thanks,
AS

2014-10-08

e-government reference model #GeGF2014 #egov #entarch #bpm #soa

My presentation "e-government reference model" at the Global e-Government Forum 2014 in Astana.




Notes contain references to some blogposts.





Thanks,
AS

2014-07-30

Technology-enabled #healthcare transformation (via synergy between #entarch, #BPM, #SOA)






Concept paper abstract - please contact me of you want to have a look at the full paper and provide your feedback

We believe that healthcare sector needs a disruptive transformation:
  • healthcare should be more affordable; 
  • healthcare should offer the best possible services for each patient; 
  • healthcare should become the centre of the health value-stream; 
  • healthcare should seamlessly incorporate innovations; 
  • healthcare should be secured by design; 
  • healthcare should prevent unjustified proliferation of tools. 
Our experience shows that systems of the complexity as healthcare must be carefully architectured to
  • avoid duplications, 
  • mitigate execution risks, 
  • enable coordination, collaboration and cooperation, 
  • build mutual understanding among all participants and 
  • explicitly demonstrate how the system will address stakeholders’ concerns. 
To address two essential challenges: 1) “functional silo” nature of the modern healthcare ICT and 2) high level of diversity between IT-enabled healthcare implementation initiatives, this concept paper proposes a platform-based approach for realisation of healthcare platform.

The concept paper explains this approach via a coherent set of the following views:
  • Big picture of healthcare 
  • Reference functional architecture 
  • Enterprise as a system of processes 
  • Security enhanced by the use of processes 
  • Some participant’s view 
  • Platform-based approach 
  • Implementation practices 
  • Project management practices 
  • Multi-layer implementation model 
  • Agile solution delivery practices 
  • Various technologies around 
  • Modernisation of applications to become process-centric 
Majority of those views are briefs on more detailed and proven methodologies and technologies.

The concept paper provides as well a mapping between views and the following stakeholders: Citizens, Patients, Professionals, Healthcare self-regulators, Governmental regulators, Service providers, Medical research, Vendors, Insurance, Information systems architects, Project managers.


Thanks,
AS


2013-10-29

#entarch to help #healthcare

The huge cost of failed healthcare projects confirm that the problem is systemic. To solve it let us expand the scope to the whole healthcare eco-system. Without doubts, each healthcare organisation within the eco-system has its unique business processes, but those processes are “constructed” from typical business working practices. The latter can be common for any sector as well as specific for the healthcare sector. Thanks to BPM, these working practices can be formalised as actionable (e.g. in BPMN) process fragments.

So, instead of spending money to implement unique business system for each healthcare organisation, let us consider a common platform, which allows to easy implementing unique business processes from a coherent set of world-class working practices and deploy this platform into each healthcare organisation.

Healthcare reference model

To have such common platform, a healthcare reference model must be developed and accepted. For example, it can be based on the synergy between:
  • knowledge management, 
  • use of processes to better manage the Healthcare, and 
  • existing achievements in the standardization of the interaction between medical applications, HL7.

Platform-based implementation architecture

A platform-based implementation architecture (http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html) is based on the following considerations:
  • The platform must standardise and simplify core elements of future enterprise-wide system. For any elements outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.
  • An agile approach requires coordination at a system level.
  • To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
  • Existing elements of the platform also need periodic challenge. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.

Forthcoming innovations faster

The platform will accelerate the implementation of following technology-enabled innovations.
##
Innovation
Technology-enabled techniques
Impact
1
Medical records are safely managed and properly share among the participants of the eco-system
Security is compared with private banks.
Well-structured data.
World-wide access for patient’s data.
Comprehensiveness of personal data.
Anonymous by Owner data for analysis and consultations
2
A patient can visit a doctor remotely
Video conferencing.
Avoid hassle for trivial cases.
Better traceability.
3
A patient can provide some simple “measurements” (pressure, temperature, sugar in blood) remotely
Smart devices and connectivity.
Systematic caring, faster alerting to prevent complex situations.
Better traceability.
4
Best specialists can provide consultation to an anonymous patient and recommend him/her the best possible treatment
Video conferencing.
World-wide access for patient’s data.
Improving the quality of treatment.
5
Patient is guided for home-based treatment
Predefined coordination and alerting (e.g. for taking pills).
Systematic monitoring.
Better supervising
6
All participants of the health-care ecosystem are electronically interlinked: doctors, hospitals, labs, pharmacies, insurances, government agencies
Secured exchange of data.
Higher quality of data.
Less overhead.
7
Other social (from governmental agencies), scientific, professional (3rd party reviewing), and commercial (express delivery) services can be plugged-in
Standard interfaces for services in standard processes.
Cost management.
Opportunities for small and local businesses.
8
The joint work of all participants is coordinated in a transparent and traceable manner.
Guaranteed audit trail. Guaranteed goal.
Early catching of problems.
Continual improvement.

Advantages for everyone

The main participants in the whole healthcare eco-system and their concerns are listed below:
  • Patients – hassle-free access to the healthcare services, correctness of treatment, maximum as possible treatment at home, cost.
  • Doctors—zero routine work, access to the medical knowledge, access to medications, traceability.
  • Other service providers – minimum overhead, common (with doctors) decision making.
  • Insuring bodies – traceability, cost of overhead, correctness of treatment.
  • Insurance companies – correctness of claims, correctness of treatment.
  • Governments – overall quality, overall cost.
  • Other services – easy to have business the main participants.
Some of those concerns will be address by mentioned above innovations.

Conclusion

#entarch can help #healthcare in the following way:
  1. Define the right scope – the whole healthcare eco-system
  2. Develop a healthcare reference model (#bizarch)
  3. Architect a common implementation platform (#apparch)
  4. Provide context for the HL7 data standardization work (#dataarch)
  5. Provide context for infrastructure
The wide use of the same platform will allow Geographical expansion of services, the virtual doctor's office and unification of basic healthcare services.

Thanks,
AS