Patientory (PTOY) - Making healthcare personal on the - Ethereum Blockchain


    Free and easy way to store and manage your health information and get the best answer to any healthcare question.

    About Patientory

    Patientory is the leading provider of blockchain solutions for healthcare. The company’s mission is to drive population health management by securely assisting healthcare organizations store and transmit data via blockchain cybersecurity and smart contracts, while enabling physician coordinated care enhanced by social media inspired peer to peer patient engagement.

    Token Sale Launches: May 17, 2017 9:00 A.M PST

    Token Sale Closes: June 16, 2017 11:59 P.M PST

    Delivering a New Blockchain-Based Patient Care Model

    With promises on the part of the new Trump administration to reboot Obamacare, the U.S. healthcare system is at a crossroads. Staggering costs, barriers to patient access and quality-of-care concerns underscore the need for innovative solutions to address this key element of America’s future.

    One company firmly entrenched in efforts to address many of these prevailing issues is Atlanta-based Patientory. It endeavors to deliver population-health management solutions that assist healthcare organizations in boosting clinical outcomes through physician-coordinated care. Through the use of a patient-centered protocol supported by blockchain technology, Patientory is poised to change the way patients securely manage their health histories and interact with their clinical care teams.

    Through use of the company’s mobile app, Patientory users create an individual profile. Their medical information is then stored on a secure, HIPAA-compliant blockchain platform, allowing them to connect with care providers as well as other patients who have similar health issues or concerns. This allows patients greater control over their overall health across multiple care teams, both inside and outside of the hospital.

    The company’s genesis is tied to the 2016 inaugural class of the Boomtown Health-Tech Accelerator in Boulder, Colorado. This led to a collaborative exchange with the Denver-based Colorado Permanente Medical Group, part of the Kaiser Permanente consortium, based in Oakland, California.

    Despite its startup status, the company has established a deep footprint in the healthcare landscape. For CEO Chrissa McFarlane, who has over 10 years of experience in the industry, Patientory reflects her personal journey and frustration with patients not having access to a central depository of their own health information and to a supportive community.

    • Facilitating Patient-Centered Care

    McFarlane notes that while the Affordable Care Act reflected the Obama government’s effort to create a more unified health system, in the current state of chaos, the solution ultimately boils down to the individual having the necessary resources to make informed decisions regarding their health.

    “Our platform is primarily patient focused. We make it easy for patients to connect with their health, which includes their information, caregivers and a peer community of individuals for support. Unfortunately, this has never existed in the U.S. And while other healthcare companies are trying to achieve similar goals, it’s on a very siloed level.”

    From a clinical standpoint, the Patientory app makes it easy for a patient care team to interact and share data, including medication and overall health history. Physicians and other care providers can therefore coordinate care over the continuum of a patient’s care journey.

    Similarly, patients can interact with all of their physicians at once, in real time, fostering greater coordination of care efficiencies and cost savings. This is a valuable feature for patients with chronic conditions who often deal with a host of physicians, specialists and subspecialists who play a role in their care.

    Moreover, the portability of their health records allows a new physician easy access to their health histories, reducing the burdensome take of having to reinvent the wheel whenever a new health provider is contacted.

    • Security

    In light of the growing number of data breaches facing the healthcare industry, blockchain technology’s major value proposition within the healthcare sector revolves around its robust security protocol, which makes HIPAA compliance feasible for both patients and providers.

    Built on the belief that decentralized hospital records improve information security, Patientory employs data networking and medical information storage in a manner that allows patients to manage their own health data repositories, thereby improving overall patient care and well-being.

    From electronic health information confidentiality to security threats identification to disclosure protection, Patientory’s employment of blockchain technology helps the healthcare ecosystem mitigate damaging data breaches. Unlike electronic health records, which are vulnerable to hacks, blockchain technology is able to utilize a more secure, permanent record of online information exchange.

    • Greater Efficiency

    On a macro level, Patientory’s ability to coordinate care greatly alleviates the occurrence of unnecessary and wasteful services. A care team’s ability to access a patient’s health history decreases the likelihood that they’ll rerun duplicate tests. This can lead to lower costs and greater efficiencies in the overall continuum of care.

    “Our primary health moonshot goal is cost to zero,” says McFarlane. “In other words the goal is to radically reduce the cost of care by a factor of a million. By offering automated treatments care plans and coordinated care through a health community network, the industry will see an 85 percent decrease in hospital readmissions/penalties along with zero healthcare breaches through decentralized blockchain technology.”

    Concludes McFarlane: “We’re anxious to see the effects of Patientory’s value in the industry, specifically how it improves the quality of life of those suffering from chronic illnesses. The uncertainty for the future of Obamacare breeds hope for blockchain technology startups like Patientory, which seeks to fill the gaps in our health system, empowering the individual patient to take charge of their own health in a proactive way.”

    by Michael Scott via

    Hacking HIPAA: Blockchain and Healthcare

    Blockchain has finally reached healthcare and making headlines! However, any healthcare provider that electronically store, process or transmit medical records, medical claims, remittances, or certifications must comply with HIPAA regulations. With Patientory, this not only applies to the provider but to the patient as well.

    Fortunately, HIPAA requires that all patients be able access their own medical records, correct errors or omissions, and be informed how personal information is shared used. So why wasn’t Patientory and blockchain created years ago? Patientory’s blockchain application to the health industry will only strengthen security for easier compliance of HIPAA best practices for the patient and provider.

    Patientory’s use of blockchain follows HIPPA Security Rules, including but not lmited to:

    • Administrative Safeguards – Assignment of a HIPPA security compliance team.
    • Physical Safeguards – Protection of electronic systems, equipment and data.
    • Technical Safeguards – Authentication & encryption used to control data access.

    This ensures covered entities maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting Electronic Protected Health Information (e-PHI), with 0 health breaches.

    Specifically, Patientory’s proprietary blockchain technology achieves 0 health breaches by:

    1. Ensuring the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain or transmit;
    2. Identifying and protecting against reasonably anticipated threats to the security or integrity of the information;
    3. Protecting against reasonably anticipated, impermissible uses or disclosures; and
    4. Ensures compliance by workforce

    Patientory is transforming healthcare, by placing the patient at the center of the health care ecosystem and increasing the security, privacy, and interoperability of health data.





    Bitcoin talk:





    Google Plus: 


    More Details About Project

    1.Current Healthcare Infrastructure

    The realignment from a \procedure" based focus to \holistic care of the indi-
    vidual" requires Care Providers form \networks" that work together towards a
    common goal of improving the care outcome of patients under care, for post-
    acute care episodes or between acute care episodes. The need for cooperation
    between care-providers ranging from specialists, primary care physicians, care-
    givers and wellness providers (like nutritionist and rehabilitation nurses) results
    in increasing use of digital technologies. Though these solutions have signif-
    icantly improved the tracking and eciency for delivering care, they have re-
    sulted in creating silos of health information, primarily within electronic medical
    records (EMR) systems.
    Health and government organizations spend a signi cant amount of time
    and money setting up and managing traditional information systems and data
    exchanges; requiring resources to continuously troubleshoot issues, update eld
    parameters, perform backup and recovery measures, and extract information
    for reporting purposes.
    Federal laws and incentive programs have made health care data more acces-
    sible, in response to hospital pushback regarding EMR implementation. How-
    ever, the vast majority of hospital systems still can't easily (or safely) share
    their data. As a result, doctors are spending more time typing than actually
    talking to patients. Physician burnouts jumped from 45 to 54 percent between
    2011 and 2014 [1].
    Although there is exist the notion of \individualized" health information
    both on the clinical as well as wellness front, these have not translated into
    \personalized" plans of care. Furthermore, even though there is a plethora of
    data, the overall healthcare ecosystem is incapable of adequately engineering a
    value or risk to big data to help better predict future care episodes of a patient.
    Hence the current solutions pursued by the Health Care technology indus-
    try have resulted in a dicult choice between care and privacy/economic fraud
    for patients. We see this issue greatly expanding as more data is being cre-
    ated by the industry. Blockchain's secure technology, properties, and
    distributed nature can help reduce the cost and eciency of these
    operations as well as provide a viable security infrastructure.

    1.1 Patient-Provider Relationship

    The new healthcare paradigm demands the need for e ective and optimal care
    delivery for patients to yield better care outcomes. This requires that Principal
    Care providers are able to actively coordinate and collaborate with other care
    providers involved and ancillary health organizations like Labs and Pharmacy
    in care delivery. Ultimately, for this to be successfully patient records need to
    be updated and modi ed in a timely manner.

    Figure 1: Patientory Schematic

    EMR software currently prohibits e ective patient-provider relationship. Pa-
    tient portals have minimal engagement among patients, as a result of the siloed
    patient experience. Furthermore, this software only provides a limited capabil-
    ity of exchange of information from one system to another and usually requires
    a designated individual who is capable of such information transfer. This has
    led to an increasing amount of delay between organizations in delivering care
    for the patient and also resulted in the overall decrease in quality of delivery of
    care services to the patient. Also, as care providers are spending more of their
    time involved in coordination of care their e ectiveness in treatment of patients
    and workload has signi cantly increased resulting in a counter-intuitive impact
    in care outcomes for patients.
    In addition, given that many doctors don't want patients to access EHRs,
    patients adopt a passive role in tracking their health. This ultimately makes
    them feel a lack of control and ownership of their health leading to the patient
    becoming frustrated and being disengaged in their care. Though there is a recent
    increase in Mobile Health Care apps helping individuals track their vitals and
    health parameters, the novelty has not translated to improved patient care or
    adherence and outcomes as it too faces the challenges of getting integrated into EHRs.

    2. System Overview

    These current issues are solved using the Patientory Blockchain Network. Legacy EMR are centralized structures subject to hacking, strict security regulations, and onerous overhead costs. By implementing the Patientory Blockchain infras- tructure, providers will see the eradication of healthcare breaches, a channel for facilitated care coordination with results in overall improvement in health out- comes. Above is a schematic describing the Patientory blockchain infrastructure and its interoperability among patients and their providers.

    3. System Implementation

    • HIPAA Regulations and Compliance Guidelines 

    Prior to any meaningful discussion of implementations, the restrictions enforced by the mandates of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) must be addressed. Those rules of primary concern are the Privacy Rule, the Security Rule, and the Cloud Computing Guidelines. The intent of this paper is not to perform a full investigation of HIPAA law. Those elements that are pertinent to the implementation discussion shall be de ned and further discussed upon the moment of relevant application.

    A. Privacy Rule 

    The business model of Patientory provides that the Privacy Rule require-
    ments must be observed due to the electronic storage and transmission of private
    health information. Applicability of the privacy rule is summarized as, \The
    Privacy Rule. . . (applies) to health plans, health care clearinghouses, and to
    any healthcare provider who transmits health information in electronic form"
    [2]. In addition to these agents, those parties that act on their behalf, as ser-
    vice providers, are also responsible for HIPAA compliance. These second hand
    agents are termed Business Associates (BA), and the legal document that de-
    nes the rules and regulations that the BA must adhere to is termed Business
    Associate Contract (BAC). HIPAA places strict requirements on the nature of
    these agreements.
    The points of merit, from an initial investigation, are those requirements
    that specify the authorization of use, the use of de-identi ed information, and
    the de nition of private information. Private health information (PHI or ePHI
    for electronic data) is de ned as \all individually identi able health information
    held or transmitted by a covered entity or its business associate, in any form
    or media, whether electronic, paper, or oral"[2]. De-Identi ed health informa-
    tion is de ned as \Health information that does not identify an individual and
    with respect to which there is no reasonable basis to believe that the informa-
    tion can be used to identify an individual is not individually identi able health
    information" [2]. De-Identi ed data use restrictions are summarized by the fol-
    lowing, \There are no restrictions on the use or disclosure of de-identi ed health
    information. De-identi ed health information neither identi es nor provides a
    reasonable basis to identify an individual" [3]. The boundary of identi able
    data to de-identi able data is de ned as any information that may restrict the
    possible number of individuals a collection of information is associated with to
    less than 0.04% of the total US population.

    B. Security Rule and Cloud Computing Guidelines 

    Due to the length of the content associated with this topic, only those el- ements of primary concern are isolated for reference. These primary concerns are as follows, \When a covered entity engages the services of a CSP to create, receive, maintain, or transmit ePHI (such as to process and/or store ePHI), on its behalf, the CSP is a business associate under HIPAA. Further, when a busi- ness associate subcontracts with a CSP to create, receive, maintain, or transmit

    ePHI on its behalf, the CSP subcontractor itself is a business associate. This
    is true even if the CSP processes or stores only encrypted ePHI and lacks an
    encryption key for the data. Lacking an encryption key does not exempt a CSP
    from business associate status and obligations under the HIPAA Rules. As a
    result, the covered entity (or business associate) and the CSP must enter into
    a HIPAA-compliant business associate agreement (BAA), and the CSP is both
    contractually liable for meeting the terms of the BAA and directly liable for
    compliance with the applicable requirements of the HIPAA Rules" [3].
    Covered entities often use cloud storage providers (CSPs) to store health
    information, often citing that it is more cost e ective and there are lower IT
    management costs. However, as consumers rely on cloud providers to store
    personal data, they relinquish direct control over that data and, as a result
    are unaware of who has access and where the data is geographically located.
    Even if an explicit business associate agreement is developed between the BA
    and the cloud storage provider, it would only provide the terms of who takes
    responsibility of the privacy and security of the data in the event a breach occurs.
    The consumer would potentially have control over access to these data streams,
    but would rely on the cloud storage provider to enforce those privileges.
    Although the use of cloud storage is popular, there are still a number of
    risks that a consumer undertakes when using this mechanism for their personal
    data. In cloud-based architecture, data is replicated and moved frequently so
    the risks of unauthorized data use increases. Additionally, multiple individuals
    with access to the data, such as administrators, network engineers and technical
    experts that cover a wide area of servers in which the information is stored. This
    also increases the risk of unauthorized access and use.
    However, even if the data is secure through strict access controls and is
    encrypted at its point of origin and while in transit, it still poses a problem
    for the development of Patient-Reported Outcomes Measures (PROMs). The
    concept of a PROM is to develop a patient-focused measure that relates to an
    area or focus that is of concern to the patient, and one in which their engagement
    and feedback is essential for its successful implementation. Accessing large data
    streams from a variety of devices that are part of the IoT network as used now
    in conjunction with cloud based services can provide a foundation on which to
    base a PROM, but it is dicult to know whether that data siloed in the cloud
    will produce a measure that will have the intended meaning and relevancy for
    a patient.
    Implementation of blockchain technology to ensure and enhance data se-
    curity for all the medical records associated with the system can achieve zero
    health breaches and ultimate decentralization of record ownership. The pro-
    cess of encrypting data when sent to database using di erent algorithms and
    decrypting it during the retrieval will be used.
    In regards to the rapid growing number of data breaches facing the
    healthcare industry, blockchain technology makes HIPAA compliance
    feasible for both patients and providers.

    C. Blockchain System Analysis of Limitations due to HIPAA Re- strictions

    The Ethereum Blockchain facilitates a diverse subset of system implementa-
    tions due to the application of a Turing complete programming language that is
    executed on the Ethereum Virtual Machine. These systems have limitations in
    that the virtual machine has no direct outward facing inspection of the broader
    internet except through the use of Oracle Services. Additionally, the storage
    limitations of the blockchain are enforced by the gas cost of storage and gas
    cost of access to this data. As of this writing, the block time of the chain
    establishes a minimum bound for state modifying requests of at least fteen
    The limitation of the blockchain to host private information may be over-
    come through data obfuscation, such as encryption, but in the event that the
    decryption key is ever leaked, there is no way to remove the sensitive data it-
    self from the blockchain. For the purpose of HIPAA compliant data, this may
    potentially result in a persistent, uncorrectable leak of information due to the
    immutability of the blockchain itself. Although de-identi ed data may, in the-
    ory, be stored on the Public Ethereum Blockchain, it would be disastrous to
    assume that the de-identi cation ltering mechanism will never fail, or that the
    sideband information associated with blockchain interactions can not inadver-
    tently reveal identity. This conclusion was also reached by the MIT Media Lab
    during the formation of the MedRec Protocols and summarized in the MedRec
    Whitepaper [3]. Mining this sideband information may be as simple as observing
    timestamps and interactions with known data storage contracts.
    Through this analysis it may be possible to associate an individual with an
    institution, and more importantly the time during which they were present at a
    facility. Given the specialized nature of some facilities, this is enough informa-
    tion to constitute a violation of HIPAA compliance due to a passive observer's
    ability to infer both identity, location, time of interaction, and possibly, class of
    Pending that this location is remote in nature, the reduction to less than
    0.04% of the US population becomes trivial. These facts constitute unreason-
    able single point failures that must be acknowledged. Further, the direct storage
    of even encrypted information on the blockchain creates a responsibility of the
    database managers to enter into a BAC due to their actions as a HIPAA data
    storage facility (See section titled Security Rule and Cloud Computing Guide-
    lines). This is an unreasonable expectation since every miner, and even those
    individuals hosting passive nodes, would all need be HIPAA compliant. Due
    to these concerns, we implement a mechanism for the persistent storage of sen-
    sitive information through the use a private implementation of an Ethereum
    based blockchain.

    D. Implementation Goals for Usability and Security 

    The primary goals of any secure system may be summarized as the goals of con dentiality, integrity, availability, accountability and information/identity assurance. In order to accommodate these goals an attacker and user must be de ned. Each of these roles demands certain acknowledgements of ability. From the perspective of the user, the system need be suciently transparent that no advanced knowledge is needed. Also, due to the inability of the normal user to grasp the complex considerations of cybersecurity, the process needs to be resistant to the actions of the user. In the event that an attack does occur, the system is created such that the amount of e ort that must be invested to compromise a resource is worth more than the value of the resource itself. This is due to the realization that a suciently advanced party with appropriate resources will always be capable of violating any system, given enough time and e ort. More compactly, there is no perfect defense. With these restrictions in mind, the implementation itself may now be discussed such that we achieve all of the goals previously mentioned.

    • De nition of Hardware and Network Implementation 

    To accommodate the above stated design goals, the selected system implemen- tation requires several independent systems. Each system subdivides authority, ensures only authorized entities may interact in an approved manner, and pro- vides a mechanism to increase security while maintaining availability. This system has also been devised such that scaling may be readily accomplished through the addition of hierarchical calling schemes. These systems are fully described in detail below. The public facing entity is a Remote Procedure Call (RPC) Server that acts as an interface to a private implementation of the Ethereum Blockchain (permissioned blockchain). This network of blockchain nodes, is only authorized to interact with the other blockchain nodes, a key authoring entity, the HIPAA compliant storage facility, and the RPC Server. The key authoring entity is the resource that generates private/public key pairs for use on the blockchain. The HIPAA compliant storage facility hosts the actual data that constitutes electronic private health information (ePHI). When a request for data does occur, the HIPAA compliant system may be authorized to speak to the forwarding agent, who then re-routes data back to the RPC server. Alternatively, it may be structured such that the HIPAA storage speaks directly to the RPC server. Each implementation has bene ts that must be considered prior to nal selection. In either event, the HIPAA storage facility decrypts the relevant portions of the database upon request handling. This decrypted information is then re-encrypted using the public key of the requesting party for transmission. This public key is also the public key of the contract that acts as the control interface from the blockchain to the HIPAA data. The following is a diagram of the network topology:

    • Definition of Software Implementation

    In addition to the physical isolation of systems in the hardware and network
    implementation, software access control facilitates the integrity of data and
    veri cation of authorization for requesting entities. The software system, from
    the perspective of access control and data encryption is described below.

    Figure 2: Patientory Blockchain Network Topography

    The HIPAA compliant database will only accept inbound connections from
    the HIPAA forwarder. This ensures that the
    ow of trac is isolated to known
    controlled paths. The HIPAA forwarder will only act to forward a request to
    the HIPAA storage facility pending a valid transaction has occurred on the
    blockchain, and this transaction resulted in the emission of a requesting event.
    This requesting event need contain the public key of the requesting party, and
    those data elds being requested. Finally, the RPC server uses an access con-
    trolled Application program interface (API) such that only known users may
    interact with the server.
    In order to understand the call hierarchy of the system, the contract structure
    to facilitate access control must rst be addressed. Every user in the system
    maps to a private address on the private blockchain. Every private address is
    only authorized to directly speak to ONE contract on the block chain. This
    contract is the individual's class contract. Institutions, institution employees,
    and customers are class level objects.
    These class level objects are permission-based interfaces. The Institution
    Contract has a list of all customers that have granted viewing privileges to
    the institution and each customer contract has a list of all institutions that
    it has granted permission to. The contract held by the institution has func-
    tions that facilitate any revocation of permissions to the institution, from the
    user. The institution contract may not self alter this list, thus pre-
    venting unauthorized access to individuals' records. Additionally, the
    Institution Contract possesses a list of authorized employees that it is fully ca-
    pable of maintaining. This permission scheme should ideally function such that
    automatic revocation of a permission is performed at semi-regular intervals to
    prevent an institution from inadvertently preserving former employees' access
    Within this system, all external parties interact through the submission of
    signed transactions that encode the requesting call. These transactions are
    submitted through the RPC server upon user validation. The RPC server posts
    these requests to the data aggregation server who then forwards these requests
    to the miners based on a load sharing mechanism. The miners then process the
    request by submitting the transaction on behalf of the calling party to the party's
    respective controlling contract. This contract holds the permissions of the data
    that the entity is authorized to access internal to the contract. This contract is
    the only entity that will accept a transaction from an outside request. Thus, a
    mechanism is established to fully control call operations on the blockchain.
    For any given transaction, an immutable record of the calling party is cre-
    ated. This ensures that all attempts to access information are recorded. The
    actual data stored within the user contract is a system of hash pointers that
    when resolved by the HIPAA storage server result in the return of the appro-
    priate data. This information is bubbled up to the HIPAA forwarder by the
    execution of a valid request transaction. The mechanism that facilitates this
    communication is indirect and manifests through the blockchain event mes-
    saging system. Due to the limitation that the requester may only query the
    database by valid transaction, and the user may not directly alter their own

    information, access control is provable. From the perspective of institutions, the mechanisms are similar except the institution contract hosts a list of users from whom it may request data and a list of users who may interact

    with this institution as employees. When a request transaction originates from the con- tract of an institution employee, the controlling contract calls the institution contract, who calls the user contract to ask for the data pointers that resolve ePHI. Pending the institution is on the list of approved institutions for the user, the contract returns the appropriate hash pointers. These pointers are then published as an event message that again bubbles up to the HIPAA storage facility. For clarity, the full process of a single request is as follows: The external party requests data from the service by calling the RPC server with a cryptographically signed transaction for submission to the blockchain. The RPC server veri es the external party's identity via the signature of a login request. Pending the signature matches an entry in the database of permissioned public keys, the RPC server accepts the request and submits the request to the Data Aggregate Machine. The Data Aggregate Machine then submits the requests to the private blockchain veri ers. The veri ers receive the request as a call from a blockchain account against a target contract. The veri ers execute this call, and in the event that the request is an allowable action, the transaction is entered in the next block. This transaction also causes the emission of an event message in the blockchain. This event message is observed by the HIPAA Forwarder, who acts to create an encrypted request against the HIPAA storage based on the hashes of the event message. This message also contains the public key of the requesting party. The HIPAA compliant database system observes this request and transmits an encrypted copy of the information to the RPC server using the public key of the requesting party. The RPC server then returns this information to the requesting party by remapping the requesting IP to the public key in the message. The RPC server transmits this message without ever having seen the underlying data. This data is then immediately destroyed by the RPC server, thus ensuring that the RPC server acts as a conduit that need not be HIPAA compliant. The mechanism to publish data is again similar in nature, but the data that is to be submitted is encrypted with the public key of the HIPAA storage facility. The other operations are identical except the data that is being posted bubbles up through the event message system. Thus, due to the use of low collision hashing functions and timestamped nonces, data may be stored with the contract being capable of computing the address at which submitted data is located within the HIPAA storage facility. Finally, the distribution of private keys to entities must be addressed. This may be facilitated through optical means to smartphone users. This is analo- gous to the use of QR codes as addresses for Ethereum addresses. Alternate means may also be established using applications on both desktop computers and tablet/smartphone devices. The loss of a key is not a catastrophic event, due to the ability to administratively strip a controlling contract's access control

    from one key and grant it to another.

    • Interoperability

    EHR systems are based on an isolated credential validation architecture in which
    patient data is kept in each of the separate systems. This has resulted in one-to-
    one care co-ordination software \add-ons" solutions to these systems to enable
    the coordination of care across other providers and ancillary health organiza-
    tions. However, the access of the information from the principal Provider organi-
    zation to the other organizations is only via limited capability in instances such
    as to Read, to Submit, to Send or to Notify. Furthermore, the Patient/Consumer
    has very limited interaction or involvement in this exchange of information. In
    addition, any error related to the mis-communication or error is very hard to
    Once a blockchain and its smart contracts are con gured, the parameters
    become absolute. The patient becomes the primary intermediary in sending
    and receiving health information negating the need for frequent updates and
    troubleshooting of any software. Since blockchain records are also immutable
    and stored across all participating users, recovery contingencies are unnecessary.
    Moreover, blockchain's transparent information structure could abolish many
    data exchange integration points and time consuming reporting activities.

    • Processes and Scalability 

    Users are in control of all their information and transfers which ensures high quality data which is complete, consistent, timely, accurate, and widely avail- able thus making it durable and reliable. Due to the decentralized database, blockchain does not have a central point of failure and is better able to withstand malicious attacks.

    Figure 3: Blockchain Process Flow Diagram 

    In any Care network it is necessary to ensure that participants who are col- laborating together can depend on each other to deliver the necessary services

    that are expected of them. To achieve that, there has to be a means to ensure
    accountability of task and services that are expected to be delivered in a timely
    manner and also associated liability if they are not delivered in a timely manner
    at the level of quality that is expected. Hence, any Health Care infrastructure
    has to be capable of seamlessly being able to monitor the necessary information
    to enable the Primary Care Provider to evaluate his Care network. Further-
    more, as the Care network grows and these interaction between network care
    providers increase the Health Care infrastructure should be capable of e ectively
    addressing this scale.
    The key aspect to building a highly scalable and distributed Care Man-
    agement system is a peer-to-peer architectural framework. Such a framework
    has already been used in a number of industry segments like, media, sports,
    real estate, supply-chain, displaying blockchain can easily be an add-on soft-
    ware connector to existing centralized frameworks[7]. This has led us to explore
    using the block chain framework for its applicability to help with enabling a
    peer-to-peer framework for healthcare.
    Block-chain holds the promise of validating two or more entities engaged
    in a \healthcare transaction". This provides two key attributes compared to
    a centralized authentication model. The rst being, that interested parties
    can engage with each other at a \transaction level" of \trust relationship".
    The second is that the liability exposure in such a relationship is limited to
    only \transaction level" engagement. This is very useful as it limits the access
    of information and liabilities between parties involved and at the same time
    enables a party to get into a transaction relationship with a number of other
    providers based on their speci c capabilities and type of care to be delivered to
    the patient. This is signi cantly better than a conventional centralized systems
    needing to limit the number of providers for a wide range of patient needs due
    to e ort required to manage the access and liabilities.

    • Health Information Exchange and Tokens

    In order for the US to successfully move away from the fee-for-service model
    to the current value-based model, there has to be a healthcare IT infrastruc-
    ture that allows organizations to link quality, value and e ectiveness of medical
    interventions through a reputable compensation model.
    Compensation will be based on how e ective the network of providers' work
    together to ensure improvement in the quality of care and wellness outcome
    while at the same time reducing associated care cost. To truly incentivize dif-
    ferent participants in the network to pro-actively create better care regimes, a
    merit based compensation of shared savings (reimbursements) takes e ect. In
    order to e ectively allocate a proportionate share to the provider in the net-
    work that contributed the most towards the overall savings a clear tracking of
    their contribution is measurable executed by smart contracts on the blockchain
    network .
    Another key impact of the new healthcare paradigm is the compensation
    model where-in the providers are eligible for receiving additional compensation

    beyond the care delivered. This compensation is the result of savings that are generated based on how e ectively the providers manage the care of the patient's health outcome (incentives). Any savings generated through ecient management of the patient's care can be retained by the providers and their network partners as part of the shared savings aspect of the new healthcare paradigm. Our proposal renders the ability for payors to transfer tokens as incentives to providers that achieve these quality metrics. The ability to seamlessly track and manage smart contracts in which the bene ts can be redeemed with signif- icant ease provides the necessary \carrot" for providers and patients to actively engage in a symbiotic collaboration. Contrarily, if one or more participants fal- ters appropriate penalties, via liabilities, can also be levied with similar ease. This \carrot/stick" approach will provide the necessary push that is needed to shift the healthcare industry from a sickness management mindset to a wellness lifestyle mindset. Henceforth, Patientory issued tokens (PTY), is the native token of the Pa- tientory platform. In exchange of PTY tokens, users will be able to use the network to rent health information storage space, and to execute health speci c smart contract payments and transactions. We rmly believe that using a token is the best payment system to support this infrastructure for the foreseeable future. The future is a vibrant ecosystem of many tokens, for which healthcare will need a closed loop payment system in place. The result will be an ecient care cycle management positive feed- back loop with signi cant decreases in billions of dollars currently attributed to healthcare payment fraud [4]. The system also incentives those large organizations with ample server stor- age to trade tokens with small to medium sized healthcare organizations that will need direct access into the blockchain health network without directly im- plementing a node. Though, the new healthcare policies provide the potential to incentivize providers to work together to improve care pathways, the current EHR architectures come short of enabling this ability, thus, simply granting or receiving tokens facilitates this process. Therefore, the value of the tokens are tied to the volume of transactions executed in the network. As the Patientory network consistently increases in token transactions the demand for the token increases, resulting in increased value.

    • Token Acquisition PTY 

    can be acquired through Patientory's native app, crypto-currency market and from another patient, physician or insurer via transfer. Platform users will have the ability to acquire PTY by sending Ether (\ETH") to the PTY creation contract on the blockchain during a pre-sale. The Patientory interface will integrate third party trading solutions such as Shapeshift and Coinbase for users who do not have ETH.

    Figure 4: Patientory

     Token Value as a Function of Transactions The Patientory Token initial distribution will be in the form of a presale. Anyone will be able to acquire PTY at a discount rate by pledging ETH into the token sale smart contract. Those with other cryptocurrencies such as ETC or BTC can create PTY via a third-party conversion service that will be available on the pre-sale page. The founding team will receive a 10% allocation of PTY, subject to a twelve month holding period. These tokens will serve as longterm incentive for the Patientory founding team. An additional 20% will be allocated to the Patientory Foundation fund to be used for research and development regarding blockchain technology for healthcare use cases.

  • Cont.. from page1

    • Smart Contracts and Insurance claim processing

    A. Auto-adjudication

    The complexity of medical billing and the third-party reimbursement pro- cesses for patients often leads to confusion or misunderstanding between patient, medical provider, and insurer. These complications lead some consumers to be unaware of when, to whom, or for what amount they owe a medical bill or even whether payment was their responsibility or the insurance provider. Patientory is a platform engineered to leverage both Ethereum blockchain technologies and Fast Healthcare Interoperability Resources (FHIR) compliant APIs to increase eciencies, enable near real-time claim adjudication, provide transparent agreements between stakeholders and decrease fraud.

    FHIR was created as an industry standard to format data thereby reducing integration complexity for healthcare and insurance legacy systems. A key as- pect to our solution, due to the cost of adding data to the blockchain, is limiting that data to only what is needed for the smart contracts to execute. With Billing and Insurance Related costs expecting to reach 315 Billion dol- lars (USD) in 2018 and medical oces spending 3.8 hours each week interacting with payers, our platform can bring substantial relief to these operational costs. Those same methods that may be employed for the analysis of cross correla- tion for diagnostic information may be used to analyze claim data for fraudulent activity. This analysis may also reveal actions such as drug seeking behavior due to the instance of multiple claims. Both of these use cases add value proposi- tions for the use of this system by insurance companies, but the ultimate bene t is beyond this information. Due to the rule based system that is enforced by the smart contract sys- tem, entire coverage agreements may be encoded to smart contracts that are referenced against end users. This would allow for a medical facility to query the system to verify the existence of coverage prior to service delivery. The use of the system to host cost information also allows for the automatic billing between institutions and individuals as token based debt. Thus an institution and an individual may be readily knowledgeable of costs as they are incurred. This removes workload from accounting departments, thus additional value to system adoption. For this reason Patientory is a closed loop payment system. It is expected that cross chain linking may even allow for the secure exchange of value through the public Ethereum Blockchain. This mechanism is already solved for the arbitration of Bitcoin transac- tions, although it does require a trusted entity to act as an Oracle.

    B. Feasibility 

    Through the use of existing mechanisms, this architecture may be readily constructed. One such example would be the linking of Amazon Web Service's HIPAA compliant data storage system with the readily deployable ErisDB. This SAAS enables rapid deployment of an Ethereum smart contract capa- ble blockchain with fully permissioned access controls such as those mentioned above. The addition of the passive nodes would need to be constructed, but this is a minimal development cost compared to the development of the complete architecture. With Patientory's three-tiered Smart Contract architecture, only a subset of the features of a smart contract are implemented on the Ethereum blockchain. Complex business logic is removed from the execution path, which allows the data tier to be optimized to re ect the distributed nature of the network. The components of the smart contract package implemented on the Ethereum blockchain are the database schema, validation and veri cation of transactions that append to the ledger, and query optimization logic for reading the ledger. The business logic is pulled up above the Ethereum blockchain to a separate middle (business) layer. This logic code accesses a variety of services, including

    secure execution, attestation, identity, cryptographic support, data formatting, reliable messaging, triggers, and the ability to bind that code to schema in speci c smart contracts on any number of blockchains, allowing Patientory to plug and play into various healthcare consortiums. These services are provided in a fabric, where the individual pieces of code that support the smart contracts can execute, send transactions to blockchain nodes, and be bound to the schema in the data tier.

    • Additional Unique Bene fits

    Although a medical institution, such as a hospital should not have access to any records that have not been speci cally approved, by having users pre-authorize the sharing of information under emergency circumstances, the end user could derive additional bene t from participation in the service. With this in mind, the need of a medical facility to access the records of an unresponsive person in an emergency constitutes a situation that merits privilege escalation given the user has previously authorized this access. In the event that a person is unre- sponsive, and has their cell phone present, the institution may prove possession of an individual's device by using a secondary signature method that is avail- able from the lock screen of a smart-phone. This second key must not be the same private key as the primary account. Thus, if an institution account sub- mits a request to the blockchain containing the public key of an individual and the smart-phone of that individual has submitted an emergency signature, the blockchain may escalate privilege to allow access to medical records it would not otherwise have access to. This private key should be considered burnable and be replaced by the individual as soon as possible. In this man- ner, the secure exchange of information between an individual and an authorized institution may be facilitated in emergency conditions. Should an institution request this information without appropriate autho- rization, the individual would be noti ed of the actions. If the individual denies this request within a threshold interval, the data is not shared. Further, if an institution attempts multiple fraudulent requests, the institution may be pun- ished by revocation of privilege, monetary punishment, and/or legal actions. The damage caused by losing a cellular device is minimal due to the need for both a cellular device and an institution level key. In the foreseeable future, all insurance cards could be embedded with cryptographic micro-controllers, such as modern credit cards possess, that would facilitate the same operation independent of a smart phone.

    • National/International Health-care Priorities

    Personalized Care

    To achieve e ective superior care, a person centric approach is important. Such an approach should take into account not only the clinical aspects but the social

    and economic factors that impede one's ability to successfully engage in care

    compliance and healthy living to yield sustained wellness. To yield e ective care outcomes requires clearly identifying the barriers of in- dividual health and life situations. With the growing number of patients having 2+ co-morbidities, the \siloed" one-type of care ts-all care delivery approach is not conducive in motivating and addressing e ective care outcomes. Hence a more exible care model tailored to include patients' multi-faceted health and wellness needs has to be considered. This requires that a comprehensive, dy- namic interactive care plan in which the patient can actively track, manage and participate in his care is vital.

    Clinical Outcomes

    Patient-related outcome measures (PROMs), which focus on outcomes that are directly related to the patient, have taken on added importance and signi cance over the past several years. This is due, in part, to the increased attention focused on the patient experience of care and to provide a patient-focused as- sessment on the burden and impact of disease. PROMs can include symptoms and other aspects of health {related quality of life indicators such as physical or social function, treatment adherence, and satisfaction with treatment. They can also facilitate more accurate patient-physician communication in terms of the burden of treatment-related morbidities by providing a more detailed and com- plete evaluation of treatments for speci c conditions, such as cancer or multiple sclerosis. PROMs are distinct from traditional clinical ecacy measures (e.g., survival in cancer, smoking cessation) because they directly re ect the impact of disease and its treatment from the patient's perspective. It can examine the balance between the eciency of the treatment and its burden on the patient. It is also e ective in looking at areas such as physical functioning and overall well-being, and highlighting the ecacy and safety of treatments in relation to its over- all clinical bene t. Because the measures themselves are developed from the patient's perspective, it can also facilitate greater patient involvement in treat- ment decision-making as well as providing guidance for health care decisions. Essentially, reinforcing a blockchain PROM infrastructure reinforces the ability to incentivize providers and payors in meeting care standards.


    Blockchain will play an increasingly signi cant role in healthcare IT and bring bene cial disruption and new eciencies to every stakeholder in the ecosystem. It is vitally important that healthcare organizations understand the core of blockchain technology to ensure they are ready for the changes the technology entails. The result will be a new generation of powerful, blockchain-based applica- tions that will shape the next era of business in healthcare. For blockchain to

    ful ll its potential in healthcare it must be based on standards to assure the

    compatibility and interoperability within the siloed health care system land- scape.

  • Our token sale has been rescheduled to May 31, 2017 and ends on June 28, 2017. Our new token symbol is PTOY. 

  • Patientory (PTOY) how it work. 


    Николай Волков (Nikolay Volkov)

    today I will try to briefly talk about the already sensational start-up Patientory: Network of storing electronic medical records in Blockchain, and explaining how it works (will work for you). Link to the official website: — it is blockchain-platform, based on the distribution of electronic computation and storage of medical records. Health facilities can protect personal health information, lease computing power, servers and data centers and its unused resources through a unique private infrastructure in Ethereum blockchain. From platform, smart contracts can be performed depending on cycle of continuous patient care. Or more simply words unique program in its kind. Which can integrate such useful qualities as: data processing mobility, timely informing patient and doctor about status of health card and of course the confidentiality of data.

    At the moment there are already electronic medical cards, but their downside is that they require constant additions by a doctor who spends his working time filling out the card, instead of spending that time with the patient. Simply distracting from the original task of treating the patient (advise) and turning into typewriter mode. In addition, the use of electronic health card led to the storage of medical information, which has a detrimental effect on the economic side. Patientory will significantly reduce costs and simplify the processing of data, make transparent all operations conducted by medical institutions. Provides an easy-to-use patient portal that can contact health care providers, schedule appointments, and review treatment plans. This platform is designed for tasks such as electronic confidentiality and health information, identifying security threats to protect against disclosure, Patientory uses blockchain technologies, thereby helping the Health ecosystem to reduce violations of data corruption. Unlike electronic medical records that are vulnerable to hacking, blockchain technology can use a more secure, permanent record of information online. And one more indisputable fact in the direction of Patientory against electronic medical card is that the platform on blockchain will be able to work in any country. At that time as the emc already blocked in Ukraine because it was developed on the basis of 1C, which in turn was banned on the territory of the country. As for Patientory, this blockchain platform as well as all the rest platforms of road maps actively take root in all corners of the planet. This is evidenced by the successful cooperation with one of the largest public health organizations of the United States of America, Kaiser Permanente. Kaiser Permanente’s track record includes more than 11.3 million patients who will move to a new level of medical care this year, after the launch of the Patientory platform. As for the popularity of this project on the market, the association of medical equipment promotion SEMDA named Patientory “most highly invested company” this year.

    For 40 years the company has been working in the field of healthcare and is working to achieve the highest achievements, thereby gaining international recognition and a colossal development in this field. The team has a broad advisory board that covers not only health care but also business expertise that successfully manifests itself in the market shares in companies such as Blackberry. And since September 2016 the team has joined the developers of blockchain, specialists in public relations, market and business. That, in turn, will positively affect the development of company.

    If you are interested in all of above about developers and project, then
    you can find out more information on the official website by going to
    this address
    And also in social networks: Twitter: @patientory

  • 7 Reasons to Love Patientory (PTOY)

    The last few weeks have been an extraordinary time for Patientory. We’ve spent the better part of 16 months building a viable product and service that everyone agrees is a true game-changer and not just hype. Interest and goodwill has been strong. And then the day before the crowd sale, someone posts a “bombshell” like this in the hopes of causing disruption and FUD.

    Let’s be clear — we are THRILLED and DELIGHTED to have people asking questions. It only helps our cause. During the last few weeks, a few individuals tried to take us down by “asking questions” that they thought would make other investors turn away in fear. Instead, they only caused our requests for more information to dramatically increase. They tried to create fear, and instead only created more investment opportunities for others. Thank you!

    Lastly, before we answer all the points here, we want to urge everyone to keep calm and a level head. All of this resulting FUD is straight out of the “How to be a Troll” Playbook. Don’t fall for it, and don’t let yourself be taken in by it. At best, these people are short-term sellers who are trying to push the value down for everyone who came after them to maximize their own investment and take the resulting profit. At worse, they are competitors who are trying to undermine what we’re trying to do. Don’t be fooled and don’t do someone else’s dirty work.

    While we’ve done our best to answer every accusation here, we also encourage you to scroll down and read our final word at the end.

    TL;DR: This is baseless accusation, but not unexpected because it comes from trolls who have something to gain by tearing us down.

    — — — — — — —

    Ok, now to respond to these so-called “red flags.”

    7 Reasons to Love About Patientory

    1) No Code, Rapidly disappearing website

    RE: “no code” — The reason is very simple you can’t find any code: Patientory is not open source. Because Patientory uses proprietary and patented algorithms, there are no plans to open source the project. That’s because we are working with healthcare organizations, some of the most regulated businesses on the planet. We would still be sitting here five years from now in a bureaucratic whirlpool if we tried to open source this. Reality check: this is medical data, not some “me too” stack.

    “…each time I do you’ve removed even more info.” I take it you have proof for this baseless and thoroughly untrue accusation. Screenshots, please.

    2) Vague ideas, seemingly stolen IP

    There you go again. Another thoroughly baseless accusation without merit and without an iota of truth. You state that you’re “an expert in the field,” yet admit you can’t understand the white paper (which has been downloaded hundreds of times in the last few weeks alone).

    This is another classic tactic from “How to be a Troll 101” — throw out accusations of plagiarism to discredit work you can’t understand.

    3) Claimed partners and deals

    Patientory didn’t spring up overnight. Instead of putting up a website and going out to the world with a flashy demo for a product that wasn’t even out of alpha, we decided instead to keep our heads down and work on developing a viable product first. Please forgive us for doing things with deliberation and thoughtfulness.

    Instead of ignoring the roadmap that’s been freely available on our website ( or the Executive Summary they can freely obtain by email request, we politely urge you to read them. Both spell out the steps we’ve been taking since December 2015. Both spell out our partnership with Kaiser Permanente and the Boomtown HealthTech Accelerator.

    Also, we encourage you to check out our FAQ at Had you done so, you would have seen that we abide by strict US HIPAA Security Rules, for example, by maintaining a security compliance team, protecting relevant electronic systems and using encryption to control data access.

    You said: “Introducing ANY new product with a healthcare provider is thousands of times harder than in any other sector.” Finally, we found something we can agree on. It takes most companies at least five years to gain traction in the healthcare space. We’ve been working hard and got it done in 16 months. Just because you don’t see all the hard work going on behind the scenes doesn’t mean it isn’t being done.

    4) Team

    There you go again. This is another classic tactic from “How to be a Troll 101” — discredit the team when you think you can do it better. If you’d like a job with Patientory, there are easier ways to go about it. Please start by contacting us at [email protected] next time.

    5) Any plan at all for adoption/traction?

    You ask: “Do you understand that the failure rate for healthtech startups is nearly 100% and that teams with deep experience and tens-of-millions in venture funding fail constantly?”

    We say: Do you understand that the failure rate for TECH startups is nearly 100%, too, and yet there are still VC’s throwing millions of dollars at CEO’s who only have failure after failure to show for it? Why do they do it if the failure rate is so high? Are you attacking them with this rhetorical nonsense, too?

    You ask: “Do you have ANY kind of plan for how you will actually get healthcare providers to use your platform?”

    We say: Yes. In simple terms, it goes like this: work with a respected partner slash future customer on developing the product. Go to market with something viable with any concerns already addressed. Rinse and repeat.

    You ask: “That not even GOOGLE could successfully bring a new PHR to market?”

    We say: Because as we all know, Google is invincible. Right? It hits grand slams with every product it releases. You know, like Buzz, Lively, Answers, Dodgeball, Jaiku, Froogle, Catalogs, SearchWiki, Notebook, Wave, and Google+.

    6) Fake press/endorsements

    “Fake news.” Where have we heard that before? Oh yes, when a certain someone feels threatened or tries to change the subject, they resort to calling legitimate sources of info “fake news.”

    Here are just a few examples of the real publications that have been writing about us. Not a single one was paid or fake:

    · NPR:

    · Forbes:

    · International Business Times:

    Have you read ICO Alert? “Patientory could prove to be a revolutionary healthcare data storage system that solves the issue of data breaches.”

    Again, not paid. Not fake.

    7) Deceptively run ICO

    Ah yes. Now we know exactly who you are.

    For everyone reading along, please know that this … ahem … “gentleman” has deliberately caused disruption in the hopes of driving out others who would invest, and thereby lower his own chances for profit. His MO is simple: intentionally ask questions he knows no company would answer, and then turn around and claim that we’re being deceptive. Don’t fall for it.

    For the record, we’ve been told repeatedly that we’re running one of the most transparent and generous ICOs in recent memory. We’ve announced bonuses and given them to everyone, not just the very few or the very privileged. We just gave out 10,000+ of our PTOY tokens in two bounty showers over the past 48 hours. I personally have replied and responded to 200+ requests for pre-sale contracts over the holiday weekend. We respond to nearly every question, even when the person or people are calling us childish names and making baseless accusations.

    Bottom line: we’ve bent over backward to try and be fair to everyone. Shame on us, I guess, for trying to please everyone.

    You ask: “Do you foresee reputation issues caused by this impacting your ability to strike deals with healthcare orgs that are very reputation conscious and lawsuit-phobic?”

    We say: No, because instead of “reputation issues,” we’ve had nothing but a positive reception from healthcare organizations. The few that even care about things like slack have told us that we’re doing things the right way, handling criticism with professionalism, and advised that we should ignore the critics.

    — — — — -

    ====A Final Note====

    There is a very vocal minority that would like to see Patientory fail. They have repeatedly tried to knock us down and knock us out, but we keep getting up. They have repeatedly tried to sling baseless accusations at us in the hopes that others “will see the light” and stop supporting us. Instead, we keep getting stronger and gaining more interest. They repeatedly try to do everything they can to maximize their own investment instead of acknowledging that the more *everyone* succeeds, the more profit they stand to earn.

    We are not perfect. We have made mistakes. Instead of pretending that we are flawless and without error, we’ve done our very best to course-correct. Have we missed the mark? Sure. We’re human. But we do try to get it right.

    We encourage everyone to look at the facts. Don’t get swept up by the hype. Question the motives of detractors who hide behind false names and baseless accusations. Keep your eye on the prize — a truly secure, better healthcare system that protects patients and makes doctors’ lives easier.

    If that’s not worth fighting for, then we don’t know what is.

    Respectfully, The Patientory Team

  • Patientory (PTOY) raised $7.2 million USD on crowd sale

    At 13:30 EDT (17:30 UTC) on June 3, 2017, we’re thrilled to announce the Patientory crowd sale is fully subscribed! We raised $7.2 million USD (based on current ETH value) and issued 70 million PTOY. With 1728 investors, that’s more than 40,000 PTOY per investor!

    The screenshot below is a frozen snapshot of the crowd sale as it ended. Please note the end time is static and shows the original end date.

    All of us at Patientory want to take this opportunity to express our appreciation to everyone who has supported us along the way toward reaching this milestone. Whether it was your advice or your investment, we appreciate and thank you for your support.

    What’s Next?

    Now that the crowd sale is over, tokens will be distributed earlier than the original June 28 scheduled date. We appreciate everyone’s patience as we take the time to do a complete and proper accounting of the crowd sale.

    In the meantime, we also want to answer a few recurring questions:

    1. The top question we’re getting is how you can add a custom token to your wallet. If you are using MyEtherWallet (MEW), you can add PTOY as a Custom Token. Here is the procedure: - Click on add “Custom Token.” - Put the contract in address box: 0x8ae4bf2c33a8e667de34b54938b0ccd03eb8cc06 - Token Symbol is PTOY. - Decimals are 8. - Click save.
    2. The second most-asked question we’re getting is about exchanges. For now, we will be traded on Bittrex, TokenMarket, HitBTC, and ICObazaar.
    3. We also want to clarify some reports about HitBTC and ICObazaar.
    • After contacting both companies, we can confirm that HitBTC and ICObazaar purchased PTOY tokens during the May 2017 pre-sale.
    • Both companies have established trading instruments on their platforms, and are supplying tokens from their own previously purchased stakes.
    • The PTOY tokens being traded on HitBTC and ICOBazaar are not available for withdrawal until the official release.
    • All questions about these trading instruments should be directed to HitBTC and ICObazaar.

    If you have any questions, please don’t hesitate to drop us a line at

    — The Patientory Team

  • Patientory Update on PTOY Exchanges

    Now that the crowd sale is over, we have a brief update regarding the exchanges on which PTOY will be traded. As we previously announced, PTOY will be traded on Bittrex, TokenMarket, HitBTC, and ICObazaar. We are excited to announce that we will be traded on Liqui as well.

    More exchanges will be announced shortly.

    More About HitBTC and ICObazaar

    We also want to clarify some reports about HitBTC and ICObazaar.

    • After contacting both companies, we can confirm that HitBTC and ICObazaar purchased PTOY tokens during the May 2017 pre-sale.
    • Both companies have established trading instruments on their platforms, and are supplying tokens from their own previously purchased stakes.
    • The PTOY tokens being traded on HitBTC and ICOBazaar are not available for withdrawal until the official release.
    • All questions about these trading instruments should be directed to HitBTC and ICObazaar.

    When Will the Tokens Be Released?

    That’s the number one question we’ve received since Saturday. We do not have a confirmed date that the tokens will be released. Although we were ready to immediately release them, we have held off because an audit is underway. Once the auditors publicly release their audit (which we expect in a few days or up to two weeks), we will release the tokens.

  • Patientory (PTOY) Attending the CDC Blockchain Vendor Showcase

    We’re very excited to note that our CEO, Chrissa McFarlane, and CTO, Jesse Brown, are attending the Blockchain Vendor Showcase event today at the Centers for Disease Control and Prevention (CDC). They’re scheduled to talk Patientory, how it works, and even how the platform makes global data available in real time. That’s especially valuable in a world where time is critical in tracking a virus like Zika.

    The CDC is the leading national health institute in the United States. It is a federal agency under the auspices of the Department of Health and Human Services. Its headquarters are located near us in Atlanta.

  • Healthcare: Re-engineered and Powered by Patientory

    Recent ransomware cyber-attacks have exposed a vulnerable global healthcare IT infrastructure. Personal Health Information data is at risk. Unfortunately, legacy systems now administrate Personal Health Information (PHI) across siloed database networks. Fragmented Electronic Medical Records (EMR) create cumbersome access points and data exchanges are fraught with friction. Patientory is a patient-centered enterprise solution designed to eliminate many of these pain points.

    Patientory uses blockchain technologies to ensure end-to-end encryption while adhering to region-specific regulatory guidelines and compliance requirements. Our solution design uses encrypted middleware to meet the high-volume demands of modern day HealthcareIT. Ultimately, Patientory empowers patients, clinical care teams, and insurance providers to overcome many challenges faced within current decentralized environments.

    The goal of this post is to provide insights to our platform architecture. This post assumes general knowledge of hardware security models, identity platforms, cloud computing and enclaves (secure elements).

    Introducing the Middle-Tier to Blockchain

    Many of the early challenges developing blockchain proof of concepts (POCs) for the enterprise revolved around two prominent concerns: scaling and privacy. In addition, the limited two-tiered architecture (client/server) presents version control issues and is difficult for in-house IT teams to implement. Poor key management also is also catastrophic for early adopters.

    With time and a maturation of the technology, however, has come evolution and the use of a middle-tier in blockchain architecture. This has enabled in-house teams to develop application functionality and feature sets using familiar tools and languages. This multilevel framework provides a separation of concerns (middleware) similar to modern web infrastructures. The middle layer allows the platform to interface with existing systems and scale more efficiently off-the-chain. The business logic (smart contracts) flows securely on and off the blockchain.

    How Does Patientory Fit Into the Picture?

    Patientory creates, configures, and query blockchain-enabled smart contracts that leverage both “traditional” cloud middleware and new application services to support blockchain development for nodes on and off the chain. Within this framework, the implementation of modern application services like biometrics and OAuth, real-time data and billing, and personal health insurance information are now possible. Applications can be developed using standard development tools, reducing time-consuming learning curves for onboarding and implementation.

    Big Data applications on the Patientory platform is also implemented and executed more expeditiously a with three-tiered architecture. Using this framework, our roadmap can expand to include ingesting Big Data from multiple sources. Harnessing this data will unearth valuable insights for clinical care teams, as well as healthcare intelligence with actionable analytics for better patient outcomes.

    How We Envision the Patientory Framework

    Please see the infographic below for an illustration of the Patientory framework.

    • First, we start with the presentation layer. This is the user touchpoint for accessing their healthcare information in real time. Prescription adherence alerts, wearables data, Explanation of Benefits (EOB), and real-time data can be found here. Hospitals, Clinical Care providers and other enterprise members interface here as well exchanging information securely in the P2P network.
    • Second tier: Middleware. Oracles execute in a secure computational environment, and have the cryptographic primitives that allow them to work directly with blockchains. On the platform, business logic executes in a fabric that binds the code to a smart contract. Identity and key management, cryptographic,services,attested data and interaction with the outside world runs in this secure environment.
    • Third tier: Data Layer and Schema. This third layer serves as a distributed database of the shared truth between nodes on the blockchain. The ledger is an instantiation of a version specific contract between several different parties. Smart contracts are bound by the ledger, schema, counterparties, logic, and external sources. The platform is fully auditable and can serve to automate many healthcare operational processes.

    Looking Ahead

    We are confident that Patientory helps move HealthcareIT into the future. It’s not only long overdue, but the increasing amount of ransomware incidents demands it. Let me know if you feel the same.

    Jesse Brown, Chief Technology Officer Patientory

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.