At an HIE level:
- Initially I would focus on enabling Apps to query for and read the data available in the HIE.
- Later adding capability to publish new content.
- Initially I would focus on Document sized objects,
- Later moving to more element level.
- Likely move to publishing Documents before element level access
- For targeted Apps, that is the most highly vetted and trusted, they will be Reading and Writing at the Organization level.
DocumentsThere has been much focus lately on the publication side of Document Sharing. Great advancements in CDA content formatting. This work done largely by a set of people that work within IHE Patient Care Coordination (PCC) and the HL7 StructuredDoc workgroup. Both of these groups do much of their work together. Trying to keep up with the number of calls that they have will fill half of your week, every week, week after week.
So today we have really good specifications of how various types of Documents should look like. The C-CDA Implementation Guide is considered the pinical of this work.
Why Documents? Well I covered that before, but the short answer is that because we are looking at communicating data outside of one organization, we need to carry with the data a good amount of context of that data. Not just Provenance (Who, What, Where, When, Why), but also care setting, intention of the event, duration of the event, etc... This context is very important to the meaning of the data contained. Especially if the data is historic.
Note that Documents does not just mean CDA. A Document Sharing environment can share FHIR documents.
Apps accessing Document Sharing (HIE)In the case of a Document Sharing exchange (XDS, XCA), the API would enable an App to query for a specific Patient, and any Documents that are available for that patient. The IHE PDQm and MHD profiles are defined to do just this. One just needs to define carefully which parts of these profiles that are implemented. These parts are separately defined in the profiles so that they can be chosen alone.
The HIE would implement the PDQm Supplier actor. This actor has an API that can be used to query for a Patient record using a set of query parameters. There is no special magic in the IHE PDQm profile, it is just a FHIR Patient. By being an IHE Profile, the capability that is needed is easily specified as simply an IHE PDQm Supplier actor. The only other actor in the profile is the IHE PDQm Consumer, which is what the App would implement to execute searches.
The Document Consumer actor is the one that the App would implement, and the Document Responder is the actor the HIE would implement. This mirrors the Query/Retrieve side of XDS and XCA; so this same specification works for an XDS based HIE as a XCA based HIE or Community Exchange.
Direct on FHIR
In this case I might suggest that both sides of MHD be implemented, so that the App could Send Direct messages using the Publication API defined in MHD. This is done just like is done with XDR today, but using the more easy to implement FHIR objects.
Security and PrivacyAs with any Interoperability API dealing with Healthcare information, Security and Privacy
are important. IHE doesn’t mandate a specific Security or Privacy model, as that would be Policy. But IHE does encourage the use of ATNA, and IUA. This also described on the FHIR Site on the Security page. The SMART solution has a large following, and thus I need to recommend it over the IHE solution at this time. There is also HEART. I am hopeful they eventually merge and improve.
First step is to add a Document based Query/Retrieve interface to the HIE. This leverages all of the existing infrastructure, and all of the existing documents that have been published and made available. It benefits from all the characteristics of a Document, while leveraging the ease of implementation of FHIR.
So, an HIE regardless of architecture should implement a PDQm Source, and a MHD Document Responder. Wrap that in security from either IUA or SMART. Because the Apps are already being written to this API...
Also see my FHIR Topic