start without content

Author: bramwesselo

input/pagecontent/authorization.md

@@ -1,4 +1,4 @@
-### The authorization model
+### Authorization specifications
 
 <!-- The Shared Care Planning (SCP) authorization model is based on the authority of the Care Plan Service (CPS). This service maintains the Care Plan and is responsible for all the due diligence that is required to build up the required trust for all Care Plan Contributors (CPC) in the network.
 

input/pagecontent/care-services.md

@@ -1,4 +1,6 @@
-### Summary of IHE mobile Care Service Discovery
+### Care Service Discovery specifications
+
+<!-- ### Summary of IHE mobile Care Service Discovery
 The [IHE mCSD (Mobile Care Services Discovery)](https://profiles.ihe.net/ITI/mCSD/ImplementationGuide/ihe.iti.mcsd|3.9.0) specification is part of the Integrating the Healthcare Enterprise (IHE) initiative. It focusses on how it enables healthcare organizations to discover and address care services. It includes FHIR R4-based resourcetypes Organization, OrganizationAffiliation, Location, Practitioner, PractitionerRole, HealthcareService and Endpoints. IHE mCSD has defined profiles for concepts Facility and Jurisdiction.
 IHE mCSD uses standard FHIR REST queries to, periodically, collect/update all resources in a central (e.g. National) repository. It also uses standard FHIR REST queries to search/select resources from a central repository. Key features for resourcetypes used in SCP:
 - Organization: Organizations are “umbrella” entities; these may be considered the administrative bodies under whose auspices care services are provided. An organization has a unique identifier and may have additional administrative attributes such as contact person, mailing address, etc. Departments of an institution, or other administrative units, may be represented as child Organizations of a parent Organization.
@@ -84,4 +86,4 @@ A CSD endpoint will perform the IHE mCSD role of 'Care Services Selective Suppli
 
 ### requirements for Care Service Directory service
 
-A CSD node/client will perform the IHE mCSD role of 'Care Services Update Consumer'. It should periodically loop through all SCP node and fetch any changes in the registered entities and merging those in the repoository of the CSD. 
+A CSD node/client will perform the IHE mCSD role of 'Care Services Update Consumer'. It should periodically loop through all SCP node and fetch any changes in the registered entities and merging those in the repoository of the CSD.  -->

input/pagecontent/careteams.md

@@ -1,4 +1,5 @@
-### Summary of IHE Dynamic Care Team Management (DCTM)
+### CareTeam specifications
+<!-- ### Summary of IHE Dynamic Care Team Management (DCTM) -->
 <!-- The FHIR CarePlan resource is a framework for documenting and managing healthcare interventions and goals. It ensures that all relevant information is available to all stakeholders, promoting coordinated and effective care delivery. -->
 
 <!-- ### Care Planning in Shared Care Planning

input/pagecontent/index.md

@@ -1,13 +1,13 @@
-
-# Motivation for NL Generic Functions IG.
+# Placeholder for introductory motivation, concepts, organization, etc
+<!-- # Motivation for NL Generic Functions IG. -->
 <!-- Rising healthcare costs are unsustainable in the long term. By making healthcare more efficient, we can ensure the sustainability of healthcare systems, safeguarding access to care for future generations. In The Netherlands, many patients visit multiple practitioners during their treatment, at different organizations. Continuous care coordination and/or collaboration comes with high costs. Currently, these practitioners either handover the patient to a different care-provider or practitioners use the same IT-system for collaboration. Both methods have severe disadvantages. 
 
 Using the Dutch handover-process, it requires the initiating party to write a hand-over-letter, collect and send data. The 'receiving' party has to read this letter and decide what to do with the data; either reconciliate (copy) the data in their own system or discard the data. The receiving party is often required to send back a 'discharge' letter after treatment. The process of handovers involves a significant amount of administrative work. When two practitioners would like to collaborate (back and forth) using this handover-process, the administrative burden increases because data might be duplicated at every handover. When more than two parties are involved in a collaboration, the handover-process is even more challenging to coordinate care and relevant/up-to-date data.
 When practitioners of different organizations use the same IT-system, collaboration is often a lot easier. These systems (e.g. a regio-wide implemented EHR or a care network/collaboration platform) usually provides members of the careteam functionality to share medical records, to communicate and to coordinate/plan care activities for a patient. The downside of these systems is that every participant of the careteam has to use that same system. In The Netherlands, many care organizations participate in multiple organization-associations. Implementing an IT-system in a group of care-organizations can be challenging and often results in a lock-in with that vendor. In some organizations, different systems have been implemented for multiple organization-affiliations. This already leads to multiple care-network-platforms that a practitioner has to use, in addition to the EHR. Switching between different applications decreases productivity and practitioner-satisfaction. Using multiple (collaboration) systems also create new silo's of disconnected medical data for a patient.
 
 Shared Care Planning (SCP) provides the structures and transactions for care planning, collaboration between practitioners by cross-organizational ordering processes, data localization and authorization of members involved in the careteam of a patient. Improved collaboration between different types of care providers (e.g. GP, homecare or hospitals) should improve efficiency in hybrid or network-care settings. It should lower the administrative burden for practitioners without having to switch to auxillary collaboration-systems. For practitioners and patients, Shared Care Planning provides an overview of related activities and participants in a care plan and care team. Shared Care Planning lowers the barriers that may exists between care organisations. Cross-organization referrals, communication or data access should be as simple and ubiquitous as a practitioner would do within a single care organization. -->
 
-### Concepts
+<!-- ### Concepts -->
 <!-- In order to create a standard for cross-organizational workflow and data access, we'll set some guiding principles:
 - Data at the source system remains the single-point-of-truth. Data may be copied from one to the other organization, but these copies are just to reduce operational dependencies (i.e. cache). An update should be always be applied on the original instance.
 - Shared Care Planning builds on international standards HL7 FHIR and IHE profiles. It is basically a selection (not an extension) of existing specifications which are used/combined to create a guide for cross-organizational workflow and data access.

input/pagecontent/notification.md

@@ -1,4 +1,5 @@
-### Summary of the notification framework in FHIR core
+### Notification specifications
+<!-- ### Summary of the notification framework in FHIR core
 
 The [FHIR Subscription Framework](https://build.fhir.org/subscriptions.html) facilitates real-time event notifications from a FHIR server to other systems. It uses three core resources: SubscriptionTopic (defining events and triggers), Subscription (describing client requests for notifications), and notification Bundles (containing an event-notification, handshake-notification or heartbeat-notification). Clients request notifications based on specific topics, and servers send them using different communication channels. There are two subscription management styles: In-Band (client-managed) and Out-of-Band (server-managed). These interactions may involve technologies like REST hooks or websockets, allowing clients to receive notifications based on predefined conditions. 
 In essence, the Out-of-Band (server-managed) style transfers much of the management burden from the client to the server, with the server being responsible for event processing, notification delivery, and system resilience.
@@ -46,4 +47,4 @@ A Shared Care Planning node shall implement the role of a **subscription client*
 The subscription client, being responsible for resolving failures, should also track the subscription's state to highlight and fix any erroneous communication.
 
 In order to implement this subscription framework in FHIR version R4, the [Subscriptions R5 Backport for R4](https://hl7.org/fhir/uv/subscriptions-backport/) is used.
-Check out the example instances for a [subscription](Subscription-cps-sub-hospitalx.json.html) or [notification-bundle](Bundle-notification-hospitalx-01.json.html).
+Check out the example instances for a [subscription](Subscription-cps-sub-hospitalx.json.html) or [notification-bundle](Bundle-notification-hospitalx-01.json.html). -->

input/pagecontent/workflow.md

@@ -1,4 +1,6 @@
-### Summary of workflow in FHIR core specification
+### Workflow specification
+
+<!-- ### Summary of workflow in FHIR core specification
 The FHIR R4 Workflow Module provides a standardized approach to managing processes and workflows within healthcare systems using FHIR standards. It defines a set of resources and operations to model, manage, and track workflow activities across various healthcare applications. This can be used for several use cases, to basically, 'ask for stuff' like:
 - Here's a drug prescription/lab order
 - Referrals
@@ -26,7 +28,7 @@ Another option would be to just use a Task resource without the 'request' resour
 
 More [advanced FHIR workflow patterns](https://hl7.org/fhir/R4/workflow-management.html) make use of a Task resource to enable negotiation and state-management for a specific request (e.g. ServiceRequest or MedicationRequest). It 'solves' the limitations of the simpler workflows, but it adds extra overhead and may add requirements for the healthcare systems of requester and performer.
 
-### Workflow in NL Generic Functions IG
+### Workflow in NL Generic Functions IG -->
 <!-- 
 In Shared Care Planning, an advanced FHIR workflow pattern is used to cover all requirements for a generic workflow process between organizations. The process is based on [FHIR workflow pattern G](https://hl7.org/fhir/R4/workflow-management.html#optiong), but SCP nodes can also use pattern [F](https://hl7.org/fhir/R4/workflow-management.html#optionf) or [H](https://hl7.org/fhir/R4/workflow-management.html#optionh) depending on the capabilities of their healthcare systems. The main difference between these 3 patterns (F, G and H) is the location of the Task; it can be stored at the requester, performer or at a third party (broker). For example; if you'd want to create a Task at the performer, but their EHR does not support it, you may choose to create a Task at your own EHR and notify the performer (and thus following pattern [F](https://hl7.org/fhir/R4/workflow-management.html#optionf) in stead of [G](https://hl7.org/fhir/R4/workflow-management.html#optiong)). SCP uses [notifications](./notification.md) in between nodes to provide quick feedback/updates in initial phase of a Task (creation to acceptance/rejectance).