Tuesday, January 11, 2022

IHE IT-Infrastructure January Public-Comment

The IHE IT-Infrastructure domain has been doing some light conversion of existing IHE-Profiles and publications to the modern html publication and use of the Implementation Guide publisher format. The public-comment is focused on uncovering mistakes in this conversion. There are no intended new features in these releases. However, there are differences that are driven by the publication platform. There is expectation that these new publication formats will enable better implementations, testing, and enhancements.

Document Sharing Metadata Handbook


IHE Document Sharing depends on document metadata, folder metadata, and submission set metadata. This handbook guides a community at defining how they will use these metadata fields. Mostly defining the ValueSets to be used within their community. Where these ValueSets might include vocabulary from national, regional, or local domains. 

The change expected in this publication is specifically just to move to the new html publication form. With html publication format there can be much more rich linking into and out of the text. So the text should be easier to understand, and easier to reference. 

Mobile Health Document Sharing

The Mobile Health Document Sharing (MHDS) shows how to build a Document Sharing Exchange using IHE-profiled FHIR® standard, rather than the legacy IHE profiles that are dominated by XDS and HL7® v2. This Implementation Guide assembles other IHE Implementation guides (Profiles) and defines a Document Registry Actor.



Version 2.2.0 is intended to be changes to the publication mechanism from WORD/PDF to an Implementation Guide published using the IG-Publisher. However, some other changes have been necessary due to the passing of time.
  • Mentions of DocumentManifest are now List.source due to the change in MHD.
  • Mentions of the PMIR Patient Identity Manager are changed to Patient Identity Registry due to change in PMIR.
  • This version has a CapabilityStatement that was not previously published.
  • Updates due to changes in the IUA profile, such as the additional leverage of the Authorization Server Metadata Option.
  • Removed section 50.7 as the current HIE-Whitepaper contains MHD and MHDS now.
  • Diagrams have been changed to support the above changes.

Mobile Care Services Discovery

The Mobile Care Services Discovery (mCSD) supports RESTful queries across related care service resources. The loosely coupled design and flexible querying capability of the mCSD Profile means it can be deployed within a variety of eHealth architectures and support a wide array of care workflows.


Version 3.4.0 is intended to be changes to publication mechanism from WORD/PDF to an Implementation Guide. 
  • Removed inline UML text and moved it to images-source/
  • Removed reference to setting meta.profile as it is redundant
  • Added sections in actor requirements describing the requirement of providing a capability statement Volume 1
  • Updated the canonical URL for the organization hierarchy extension to http://profiles.ihe.net/ITI/mCSD/StructureDefinition/IHE.mCSD.OrganizationHierarchy
  • Added links to the structure definitions for resource profiles to ITI-90 and ITI-91
  • Changed structuredefinitions for Facility and Jurisdiction to use an invariant for the type requirement instead of slicing.
  • Added in text to show that searches can use GET or POST ITI-90 Message Semantics.
  • Added in retrieve (GET RESOURCE/ID) message section starting at ITI-90
Note, there will be further enhancements in the coming quarter to enable use-cases such as using MHD to access a federation of Communities.

HTML navigation

There is now also a new feature across the whole the publications. Now wherever there is a header, you will find a link icon that you can use to get the deep link to that header. This enables easier references to sections. 

Commenting

Public-Comment is welcome from anyone. You do not need to be a member. Comments can be submitted on these in three different ways. Comments open until February 12th. 
  1. Using the Web based form found at https://www.ihe.net/ITI_Public_Comments/
  2. Using a spreadsheet emailed to iticomments@googlegroups.com
  3. Using GitHub issue submission (provided you have a Github account and are a member of the IHE github community)
    1. Metadata Handbook Issue tracker
    2. MHDS Issue tracker
    3. mCSD Issue tracker
I really want to encourage membership in IHE IT-Infrastructure committee.

Wednesday, January 5, 2022

PIXm webinar

There is now a short webinar recording available for PIXm


This and other IHE recorded webinars can be found on the IHE International YouTube channel.


The PIXm implementation guide can be found on the IHE Profiles.ihe.net site where all of the IT-Infrastructure specifications are published.

Note that PIXm and PMIR do have different feed patterns, these are intended. I explain that in this article. 

Thursday, December 30, 2021

Glad 2021 is now passed

 I am reminded of "This too shall pass.", and I really hope it is true. The past two years have been monotonous, with very little positive things to get excited about. That said, I expect 2022 will simply be a workhorse of a year with small advancements that are not clear today. Yeah, that is the most blah prediction.

The most positive is that my household family continue to be COVID-19 free. However I lost my father with COVID-19 as a factor. COVID-19 has been the healthcare story in the standards I work on, but is also the thing that is preventing the standards groups from gathering and being more productive. I don't mind the pace slowdown, and initially didn't mind the lack of face-to-face meetings, but lately I have found myself wishing for the face-to-face workgroup meetings. I likely just want some of the positive meeting dynamics, while noting that most of the time the meetings were compulsory and a waste of time.

The last time I did a year-end report was at the end of 2017 - HIE Future is Bright - stepping into 2018. Looking back at that report, it is rather disappointing that none of the expectations have been achieved, yet so much has happened toward the direction of each of these. The activities that have happened are clear now that they were necessary, but of course at the time it felt like everything was ready for progress.

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one." - Mark Twain

Over the year, my blog saw mostly the same amount of visitors (90k), and I posted mostly the same number of articles (30). The biggest impact I had this year:
  1. IHE whitepaper on Health Information Exchange models (3.7k)
  2. From Implementation-Guide to IHE-Connectathon (2.7k)
  3. Healthcare use of Identity level of assurance (2k)
  4. When is a document not a Document but still a document? (1.6k)
  5. Agile improvements toward #FHIR (1.5k)
  6. Security of #FHIR implementations concerns (1k)
It is good to see that the Alisa Knight cybersecurity attacks on #FHIR were not a big reason for visitors to my blog. 

2021 Themes

Health Information Exchange using FHIR

Healthcare IT Security

Presenting and giving Tutorials

Fun

Friday, December 10, 2021

Mantras for Secure FHIR Development

This morning I presented to the India FHIR-Connectathon on the topic:

Mantras for Secure FHIR Development

The slides are available in google slide desk. Summarized below ---


Alissa Knight -- White Hat Hacker

The New Healthcare Ecosystem will depend on FHIR APIs, but are They Secure?

My reaction
  1. EHRs are doing a good job of securing their FHIR implementations
  2. FHIR is good and worthy
  3. There is room for improvement in some implementations
  4. There are included recommended improvements.
Grahame’s reaction
  1. The report explicitly notes that no vulnerabilities were found or are documented in the EHR FHIR implementations themselves.
  2. Nevertheless, lots of vulnerabilities were found. All of them are very basic house-keeping stuff well covered in the OWASP top ten risks.
Media Hype
  1. Many media outlets did not get the facts right at all. Or even the impressions
  2. Don’t trust the media, read the report

Basic failure to secure

  1. Resource-Server not enforcing scopes in the OAuth token
    • Change the URL by the attacker (change the Patient id parameter)
    • Given a read-only token, able to change data (change a medication of another patient)
  2. Client/Server architecture where all data is sent to the Client
    • A Patient Engagement App… the client was being used by a Patient on the Patients computer
  3. Resource-Server not validating tokens
    • Intercept a legitimate client app request, extract out the OAuth token, put that token into a request from your hacking client - so enforce timeouts and refresh cycles
  4. Clients with hardcoded API keys in the app
    • Not hard for a hacker to decompile your app and find keys

Hack yourself before someone else does it for you

  • Your API or App will be attacked, better that you prepare
  • Look to cybersecurity experts - this is both a skill and an attitude
  • There are recommendations like from OWASP - https://www.owasp.org/
  • Don’t assume tokens are valid, don’t assume token authorizes the request
  • Audit Logging of everything, and regularly inspect the logs for deviations
  • Provide a way for Vulnerabilities to be reported
  • OAuth and TLS have Best Current Practices written by experts


Questions are welcome

Tuesday, December 7, 2021

Please secure your #FHIR API and Apps

 Just updated the FHIR core spec Security and Privacy Module with a simple message, yellow highlight for the new text:


FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:

  • All communications can be encrypted to prevent unauthorized access.
  • No information leaks when errors occur
  • No active script content can be injected into narrative resources
  • Full audit trails can be constructed and used to detect anomalous access patterns

For general security considerations and principles, see Security. Please leverage mature Security Frameworks covering device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security  and OWASP . These security frameworks include prioritized lists of most important concerns.

Recent evidence indicates lack of implementer attention to addressing common security vulnerabilities emphasized by OWASP top 10 API . Reviewing the OWASP Top Ten and OWASP mobile top 10  and ensuring those vulnerabilities are mitigated is important for good security.

The Security Checklist also added two new items

12 When using OAuth  - Consider the draft Best-Current-Practice for OAuth 

    13. Security / Privacy Event Reporting  - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach.


    ---------------------------------  Revised to add these notes ----------------------------- 

    Not on the FHIR standard, because it is a bit too prescriptive for HL7. These are the highest takeaways from the past month:

    1. Bad API security
      1. Take initiative, hack your own API before someone else does.
      2. Resource-Server MUST enforce authorization tickets, don't just trust that a valid ticket is authorizing the request being made -- 
        1. OWASP -API5:2019 Broken Function Level Authorization
        2. OWASP -API1:2019 Broken Object Level Authorization
      3. Don't assume any level of trust, always check tokens on EVERY transaction 
      4. Don't allow hardcoded API keys
      5. And my personal favorite, log events AND audit the logs - OWASP -API10:2019 Insufficient Logging & Monitoring
      6. Look to CyberSecurity experts, there are many. There are many tools. 
        1. HITRUST.org - they do have a useful cross-reference, and are risk based.
    2. Security / Privacy Event Reporting 
      1. One method of advertising HOW to contact your security people -- https://securitytxt.org/
      2. An alternative using DNS -- https://dnssecuritytxt.org/
      3. Great community effort, including policy templates, somewhat more oriented towards researchers:   https://disclose.io/
      4. Guidance from CERT on Coordinated Vulnerability Disclosure  
      5. Guidance from USA Department of Homeland Security-
      6. First.org guidance on MultiParty vulnerability coordination
      7. ISO 27000 compliance ISO 29147/2018 and  ISO 30111/2019
      8. A commercial product (Luta) maturity model for vulnerabilities  https://www.lutasecurity.com/vcmm
      9. a bit on bug bounties, which can be a very useful technique, but one must have a mature baseline in place:   https://bugbountycoi.org/framework/
    3. OAuth Best Practice
      1. OAuth 2.0 Security Best Current Practice
      2. OAuth 2.0 - Security Considerations
      3. TLS Best Current Practice

    Friday, November 12, 2021

    IHE conflicting Patient Identity Feed patterns

    Now that IHE has added a PIXm Feed transaction, there is now confusion between PIXm and PMIR. Let me explain.

    Overall

    The PIXm and PMIR implementation guides are intending on solving two very different models of managing Patient Identity. There is no expectation that a community would deploy both models.

    This is further explained in the "HIE Whitepaper - Patient Identity Management"

    PMIR

    PMIR model is one where a community wants to cooperate on a master Patient identity for each patient, a "golden" patient. This model has each authoritative party in the community cooperatively keeping the single Patient identity for a patient up-to-date. When a patient is seen one of the locations in the community, the master Patient identity is pulled from the PMIR Registry. If there is anything that needs to be updated, then that system will send the update back to the PMIR Registry. Thus there is only one Patient identity (demographics, addresses, phone numbers, national numbers, etc). This cooperation is what PMIR is all about.

    There are additional features in PMIR that enable those that rely on this master Patient instance to be notified of changes. This is another use of the feed. This feed does enable the data custodians to be notified of important changes like when two master identifiers were determined to actually be about the same patient and thus have been merged. In this case the data custodian is expected properly update their data to represent the merge.

    PIXm 

    PIXm model is one where a community wants to cooperate on Cross-References between each community members instance of the Patient identity as they know it. Where a cross-reference is simply a list of  Patient.id and Patient.identifier (that is a patient identity such as MRN). The cross-reference is derived at using the other elements in the Patient resource, but a cross-reference does not expose on a query interface these other elements in the Patient resource. The PIXm query is just a set of identifiers (id and identifier) that are cross-referenced. 

    Each time a community participant updates their local instance of the Patient identity, they do feed those updates to the PIXm Manager. The Manager looks at the details with the ONLY output that the PIXm Manager updates the cross-references that it would return in the future when a PIXm client asks for the cross-references. It is very likely that the PIXm Manager does remember the demographics, addresses, phone numbers, national numbers, etc... but there is no effort to harmonize these at the element level. 

    PMIR uses PIXm

    PMIR does include the PIXm Query transaction. This is useful when a client in the PMIR environment for a very few cases:

    1. When the client does not want the whole Patient, just the .id so that it can record that value. There are plenty of client use-cases where it is not important to have access to the full, and sometimes sensitive, elements in the Patient resource. For example a weight scale wanting to record a new body-weight observation, where the scale knows the PMIR Registry and knows that the weight scale GUID is recorded as a Patient.identifier. Thus this device can do a PIXm Query given the scale GUID and get the Patient .id value. It can put that value into the Observation.subject element. 

    2. When the client does not want the whole Patient, just knows the Patient .id and wants a local MRN value. Not as clear why this client does not want to be exposed to the Patient Demographics, but it is possible.

    PIXm and PMIR feed are not compatible

    So the above should make it clear that PIXm and PMIR are solving different community models, and that those models would not exist in the same community. It is possible that a PMIR community would want to be a community participating in a broader PIXm community. Thus the PMIR Registry would participate as a PIXm Patient Identity Source.

    The elephant in the room is... WHY did PIXm and PMIR feed choose totally different technical approaches at the FHIR interaction? If you didn't notice this, let me explain.

    • PMIR uses a "history" Bundle for the Feed. 
    • PIXm uses more basic RESTful Create/Update/Delete (mostly)
    Neither model is great. It is very possible that in the spring we update PMIR to more closely align with PIXm. I say "more closely" because the "expected actions" of the PMIR Registry are very different than the those of the PIXm cross-reference Manager. But the communication on the wire might be possible to be 'closer'...

    Trial-Implementation

    All this said... these implementation guides are both in "Trial-Implementation" state. This is the state used when IHE wants implementers to try it out, and give feedback to improve the future. So, please try them out, and give us feedback. Would prefer you join the ITI-Technical committee, but would also take input on the Public-Comment forum or GitHub for PIXm. I would also welcome comments on this blog article.

    Thursday, November 11, 2021

    My Father

    My father passed away this week, joining my mother. His health has been fading since his love of 70 years passed. He passed peacefully with his favorite nurse at his side, in the middle of the night.  

    During my life he was a Wisconsin State Trooper. He joined on a dare from his older brother who had joined in 1956, the next year my father joined the 6th recruit Class, badge #287.  He retired after 28 years. There were plenty of stories of my father as a Trooper. Most of what I remember is that he had friends in every little city, truck-stop, gas-station, etc. I never caught the skill of making friends that he had. 


    I learned from my father (and mother) respect for others. I know that police do not have a good reputation today, and I suspect there were bad apples back then too. But I am confident of the stories I was taught regarding "perspective". I was taught to not judge someone by the first impression, to try very hard to look at their situation from their perspective. It is when you see their perspective you realize they are fighting trying times. This perspective exercise is what enables me to be comfortable with people that are "not like me", people who make life choices that I myself can't understand, people who are down on their luck and likely would benefit greatly from the smallest of help. Perspective is key, try to walk a mile in their shoes before you judge. 

    I learned from my father work-ethic. He would work hard when doing a job, with appropriate breaks. But he would also reserve recreation time. And of course sleep.  He enjoyed odd-jobs, such as gathering up used tires to take them to the "re-tread" factory. We would fill the back of the pickup truck, nicely organized tires, three rows high. Learning how to get the rain water out of the tire without getting wet. I am sure this odd-job was never worth the income.

    When I heard of his passing, I was relieved for him. I will miss the bi-weekly visits I had with him. I went for a walk, turned on classical music (my mothers favorite) and listened for sour-notes and clinkers (my father always would). Ended up sitting in a local church prayer garden, alone with the sunset.